Arduino programing lost after reset/powercycle

I’m programming a HiFive1 board. Here is my environment:

  • macOS Sierra
  • Arduino 1.8.5 installed from the arduino.cc software web page
  • SiFive board manager 1.0.2 installed as per SiFive instructions (using a URL in the Arduino interface)
  • compiled as follows:
    • board = HiFive 1
    • tool install location = default
    • programmer = SiFive OpenOCD
    • it doesn’t seem to matter which clock freq I pick (they all compile and load, but run at different speeds, as expected)

Here are the symptoms:

  • on power-on, board successfully posts diagnostic to tty (superman logo) and cycles RGB LEDs
  • on reset, board successfully posts diagnostic (as per above)
  • Arduino can reprogram the board (e.g., the Examples/01.Basics/Blink code compiles, installs, and runs properly)
  • however, when I either power cycle OR hit the reset, the board runs the diagnostic program instead of Blink

Can anyone suggest why my code appears to be loading into RAM rather than flash (which would persist) and/or why the default diagnostic code isn’t being overwritten as intended?
(NB: I have extensive experience with Arduino platforms, including the Due, and haven’t had this problem before)

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.

Just to confirm, I run this script inside the following directory?
/Users/touch/Library/Arduino15/packages/sifive/hardware/riscv/1.0.2/ ??

And where is this flash.lds file if not already in the directory indicated in the shell script? (it isn’t)

Oh, sorry, you’re using the Arduino IDE. Unfortunately it doesn’t come with the program source code needed by this script. You can get that from https://github.com/sifive/freedom-e-sdk

git clone https://github.com/sifive/freedom-e-sdk.git

The scripts in freedom-e-sdk also need access to OpenOCD and the gnu toolchain. There are several alternatives for this (see the README on github for full instructions).

Hmm … it looks like there’s a copy of an older freedom-e-sdk in the Arduino install, and flash.lds is called link.lds there. But the Makefile looks to have diverged sufficiently that my reflashing script isn’t going to work with it.

Plus the current freedom-e-sdk also uses riscv64-unknown-elf-gcc (which can also build 32 bit programs), but the Arduino IDE package still supplies riscv32-unknown-elf-gcc. Annoying.

So I think you will have to get a fresh freedom-e-sdk and also build or download an up to date prebuilt toolchain as I said in the previous message.

Thanks - that worked.

Great! Sorry for the trouble.