Embedonomicon: Run Tutorialcontent on real hardware causes Stack corruption

Hi all,

currently i am on to follow this Tutorial right here:
The Embedonomicon - Memory layout

With qemu everything works fine. Now I want to try out this 'minimal system' on a STM32F303 Discovery Board, but I get a really interessting behaviour. First of all, i changed the linker script to match the HW Specs of my board:

MEMORY
{
  FLASH : ORIGIN = **0x08000000**, LENGTH = 256K
  RAM : ORIGIN = 0x20000000, LENGTH = **48K**
}

Starting the program works, i can connect with gdb to my board and can step through each line of code, but only if i meet the following condition:

pub unsafe extern "C" fn Reset() -> ! {
    //let _x = 42;

    // can't return so we go into an infinite loop here
    loop {}
}

As you can see, i commented out the local variable. The expected behaviour is to step infite times through the loop - works!
But if I uncomment the variable or add some more, like,

pub unsafe extern "C" fn Reset() -> ! {
    let _x = 42;
    let _y = 41;
    let _z = 40;
    // can't return so we go into an infinite loop here
    loop {}
}

then only the first line within the function gets executed, after that the PC (Program Counter) jumps to an random place like 0x123ABCF0 when step to the next command.
GDB tells sth like:

Cannot insert breakpoint 0.
Cannot access memory at address 0xfffffff9

What means, that our programm jumps out to nowhere. So, i compared everything to the qemu variant and nothing differs to each other.

Do you know if qemu does something what 'real hardware' not does by default? Initialize something more? It's strange that I can insert 1 command without problems, but if I do more commands in the Reset() fn so everything stucks. Seems like an memory issue, but I can't figure out whats going wrong here.

Thanks in advance!

P.S.: The linker script is apart from that 1:1 the same than in the tutorial

Hey there,

'shame on me' , finally found the solution - for some reason the specs from this disco board does not match to the ones in the doc. The memoryborders I wrote into to the linker script were way too big so when it comes to 'stack in' the variables the cpu tried to lay them down into non existing memory. Now I tried with the smallest version of the disco board:
Flash: 32k
Ram: 16k
It Works!

1 Like