Unable to run out of RAM after trying to flash

[wware]

Probably I'm doing something bone-headed, but: I was able to get the blink example running out of flash with both blue and green LEDs flashing. Then I got adventurous and tried blink_flash. The blue and green LEDs never lit up for that, and I think I did that wrong. But having done that, I now can't get the green and blue LEDs to flash when I try to run out of RAM. This is with a 32VL Discovery board, and my host is Ubuntu 10.04. I don't know if it matters but I had an old "arm-elf" toolchain around already so I didn't use "arm-none-eabi". Would that mess things up?

[wware]

Luckily I have a second board which was previously unopened. So I tried it, and it ran the initial blink program (where the user button changes the green flashing pattern and is echoed by the blue LED) and it ran the blink example out of RAM just fine. The first board no longer runs the initial blink program. So it's definitely something bad I've done to the board. Is there any trick for putting the first board back in its happy state? Maybe move a jumper and apply power for 10 seconds or something like that? I've seen that sort of thing on other boards.

[wware]

Managed to figure it out. Both boards responded well to the flash utility, so I grabbed a bin off the good board and used it to program the bad board, and now both boards are good. So I am closing this issue.

[karlp]

Also, those projects were simply not properly set up :( There's some outstanding work in progress to make the examples more reliable, with better documentation... Sorry about that.

[wware]

The one thing I still can't do is run the blink_flash example out of flash. I haven't investigated this at all, just blindly followed the instructions in the PDF. If I get up more energy I'll try and figure out what's going on with that, now that I know how to fix it when it goes wrong.

[karlp]

You could also look at : https://github.com/karlp/stlink/tree/master/example/blink It uses different startup code, and I've verified it with flash and sram, and running other projects in between. Really, the existing blink and blink_flash projects shouldn't be looked at.

I'm just trying to clean up my commit history to get this merged into the mainline. Hopefully over the weekend.

[UweBonnes]

Running from RAM is a difficult thing. There are two areas to observe:

• for interrupt driven programs to work you need to be in handler mode at startup. Otherwise the commands to set up interup vectors won't work. If you just run the old program, then load up the new program with stjnk and then jump to 0x20000004, there is no guarantee that you are in handler mode. Chances are, that the old program is stopped by stlink in handler mode. There are two things you can do about it: Jumper the boot selections to start from SRAM or write some trampoline code that you put into flash. This trampoline should just fetch the Stack settings from 0x20000000 and then jump to 0x20000004. With gdb you can then start the program in extended-remote with "run", or you just push the reset button.
• The other area is initialized data. If you just upload the program and run once, you won't notice. If you restart again, strange things will happen, as "initialized data" is not initialized again. Look e.g. at example/32l_lcd/linker_stm32l.lds. The read only copy of the "initialized data" is put at _etext. But there is no room allocated for that data. .rodata is also put there. Or with other linker scripts the .data section is put there. As I have found no way to allocate space in the size of the "initialized data" after _etextas the size is only known later in the script and the GNU linker can't handles a reference to a variable not yet know. I allocate some fixed space in my scripts. No a good solution, but it works somehow. With flash linker scripts. _etext is at the end of the text section in flash and .data is in ram and so they don't overlap.

[wware]

@UweBonnes - I've just been working with the LED blinking demo which is probably just some GPIO and a timing loop, so running it out of RAM has been no problem. Where I've had difficulty has been in using the blink_flash demo, programming it into flash at 0x8000000, and then being able to run it. It sounds like you are working with some other piece of code.