FIXED: Bootloader at 0x20000000 missing, need to flash it

Hello,

I just got my HiFive1 today, the board and accompanying demos via FreedomStudio do work on the device. I also have had success using the GPIO pins and Cinco via the Arduino IDE to power an Adafruit SHARP Memory Display.

However, when I press the reset button (or power cycle [unplug and then replug] the board) then the program never comes back and the board just sits there. I do not see any of the leds flash when reset is pressed either. Trying to do a safe bootloader mode does not work either (so far as I can tell).

Debugging through freedom studio when I hit the reset button has the following message appear in the debug log:

Error: TDO seems to be stuck high.
Error: TDO seems to be stuck high.
Error: TDO seems to be stuck high.
Error: TDO seems to be stuck high.
Error: TDO seems to be stuck high.
Error: TDO seems to be stuck high.
Error: TDO seems to be stuck high.
Error: TDO seems to be stuck high.
Error: TDO seems to be stuck high.
Error: TDO seems to be stuck high.
Error: TDO seems to be stuck high.
Error: TDO seems to be stuck high.
Error: TDO seems to be stuck high.
Info : dtmcontrol_idle=5, dbus_busy_delay=3, interrupt_high_delay=29

At this point, I’m not sure what I’m doing wrong. I’ve tried multiple usb micro-b cables (in several different USB ports) and DC power but I always get the same result. If I had to guess, it is almost like the board has hit a trap and is sitting there waiting for something (100% speculation on my part).

Inspecting the memory on the HiFive1 shows the OTP section is intact with the instructions described in the manual in place as well.

Here is what machine I’m running on:

OS: Gentoo Linux amd64
Kernel: 4.9.76-gentoo-r1
Freedom Studio Version: Beta 3 with SiFive Environment version 4.7.2.201801221517

Any ideas? Is this expected behavior?

So I figured out what is going on. It seems that the SPI flash is not being written to despite the memory being unlocked for writing via GDB. When I press the reset button the SPI flash is put back to all 1’s and thus the reset vector does not jump to the right area (it traps).

I get this behavior in both Arduino IDE and Freedom Studio. I even uploaded the mecrisp-quintis forth image for testing purposes and that does work but data is not commited to the SPI flash. Now that I have a clue, I’ll do some more research. I’ll keep this topic open until I figure out why SPI flash is not persisting across restarts.

I don’t quite understand. You said the Freedom Studio demo programs work. This is not possible unless they are successfully written to the SPI flash by OpenOCD.

Are you saying these demo programs disappear if you later reset or power cycle the board? That is absolutely not expected. You should be able to load a program from USB, take the board away from the PC and power it from a phone charger or other DC source, and the loaded program will work. e.g. as seen in this silly little demo I did 15 months ago https://www.youtube.com/watch?v=0eDS6pGYsCE

Thanks for the reply.

That’s what’s strange. They are written to SPI flash (I can see the program code in gdb when I inspect it) but there is no bootloader at addresses 0x20000000 to 0x2000003F which is meant to pass control off to the program itself. Originally the bootloader section was all ones but I decided to experiment with it and see if I could write anything to 0x20000000 so that the OTP would just go to the user program (I screwed up and wrote the number in backwards :confused: ). I was able to write once and only once to that memory before it was marked as protected. Subsequent attempts to erase the section or rewrite have failed (I get a verification failure from openocd/gdb).

I was able to rewrite that area of memory once I read more about how SPI flash works (I’m new to this). So I was able to perform the full erase and upload a simple arduino blink. Once power is removed the program is still in flash but 0x20000000 contains 0x20400000. I’ll need to look into this further.

EDIT:

According to the getting started guide, there should be a program at the beginning of flash which passes control off to start at 0x20400000. Mine is completely empty,

EDIT2: I found the bootloader source and flashed it successfully.

Glad you got it sorted out and there’s nothing wrong with the hardware (that would have been unusual).

@Dritanium
Hi,
I just received my Hifive1 and it is also missing the bootloader code.
Could you explain how to reflash it, please. I found the source but don’t know to handle it yet
Thanks and regards
Would like a PM but don’t find the option in this forum …

Take a look at this. It is exactly what I did:

1 Like

Many thanks for this fast answer ! It works. This is just I needed to go further :slight_smile:

Excellent :). Glad I could help.