Hi Joe, sorry about that but we’ve just learned there is a manufacturing error in a batch of boards. There is supposed to be a “safe bootloader” program at 0x2000_0000 that has a 1 second delay before running the user’s program (initially the demo program) at 0x2040_0000. Unfortunately the demo program has been loaded at 0x2000_0000.
You program is in fact being loaded into flash at 0x2040_0000 and it works the first time because gdb runs it directly after flashing it.
The following will fix the problem by loading the safe bootloader at 0x2000_0000 and the demo program at 0x2040_0000.
cd freedom-e-sdk
curl https://static.dev.sifive.com/dev-tools/flash_bootloader.sh | sh
It’s very important that you do in fact have safe and correct code at the reset entry point of 0x2000_0000 because a sufficiently bad program can lock up the processor badly enough that OpenOCD/gdb can’t load a new program. An example of “sufficiently bad” would be turning off the processor clock or setting it too high, but there are others. Reset or power cycle will fix that, but it’s not good if the bad code is immediately run again.