Board seems to be a warm brick and nonresponsive

Have not done much other than the compile the dhrystone code and then attempt to upload it to the unit. That resulted in a pile of errors. At the moment there are two green leds lit up and when I press the “reset” button I see a single blue led flash once. Then nothing but the two green leds are on. There are no /dev/ttyUSB? entries created and lsusb claims the unit is not attached at all. That to me is a warm brick. Is this thing now a fridge magnet ?

Note that page 22 of the “Getting Started Guide” describes a “safe boot” mode :

To activate “safe” boot mode, press the RESET button. When the 
green LED flashes, immediately press the RESET button again. After
1 second, the red LED will blink. The user program will not execute, and
the programmer can connect.

OKay … did that and I have a flashing pulsing red led. However no device seems
to exist connected via USB and thus no way to “connect”. What’s up here ?

My first suggestion is to insure power is supplied via wall wart, enter safe mode as described, and when in safe mode disconnect and then reconnect the USB cable. Then look at dmsg to see what happens.

Excellent suggestion! I will check the “Getting Started” guide and see what the specs are on the wall power and then give this a try. Really, all I ever wanted to do was to try a bit of assembly. A few shifts. Perhaps integer add routines. What I got was frustration. Such is the situation with first generation hardware I guess. I’ll report progress if any!

When there is no device showing up in lsusb, it is very unlikely that wrong flash content is the reason for your problem.
The UART and JTAG interfaces are implemented by the FTDI chip on the board, not by the FE310 and should work independently of the code in flash.

So I would check why the device is not appearing in lsusb.

Let me translate : the appearance of a serial device ( or not ) has nothing to do with the RISC-V processor. Why oh why couldn’t the sifive designers just leave a simple 9-pin serial 8-n-1 port on this thing?

Maybe you should take a closer look into the „HiFive getting started manual“: on the last page, there’s the pinout description. You will discover that pin 1 and 2 are labeled TX and RX, like on a standard Arduino. You can also download the schematic, it shows that the lines are wired with resistors in a way that the tx/rx pins will override the FTDI connection. So it is close to your desired 9 pin header, but with TTL or LVTTL levels (depending on the IOREF jumper).

BTW: I have a lot of development boards with FTDI chips, not only the HiFive1. They all work well so it is a proven and very common solution, and I have not used DB9 cables since years, so nothing wrong with the design decisions taken by SiFive

1 Like

Just mildly frustrated here. Oddly I am working right now on some Oracle Netra hardware and never had problems dealing with firmware and diagnostics issues but this “arduino” type thing is just entirely new to me. I was looking at the schematics and thinking that a serial port could exist in there. As for DB9 and RJ45 type ports that are 9600 baud serial, well, I see those every day on everything from switches to massive M-class Oracle servers. I am always surprised when a “real” serial port doesn’t exist on hardware for diag purposes.

Dennis, I understand your frustration, since I’ve been there too.

First, the HiFive1 board is an Arduino board. If you use it with the Arduino environment, you generally manage to upload your application and it runs as expected. As usual in the Arduino world, it generally does not allow customizations, the Arduino environment provides the startup, the linker scripts, the main code, the libraries, and generally everything.

Second, by design, the Arduino development does not allow debug, and there is nothing to do about this.

Given the above, the HiFive is a decently reliable Arduino board. Based on my experience, sometimes you might need 2-3 attempts to upload your application, but regardless how messed my board was, the Arduino environment always revived it.

However, if you try to use the HiFive1 outside the Arduino environment, well… your mileage may vary. :frowning:

I was probably the first embedded user to try complex development with the HiFive1 (while working on the Eclipse SiFive templates), and my conclusion was that the board is not usable; with code under development the board was bricked almost each time, and flashing it required booting to bootstrap and multiple attempts before succeeding.

In fact, after a while, I gave up, and I developed the templates using the E31-ARTY, which had a proper JTAG connector and I could use the J-Link.

The reasons for the board bricking are somehow complicated, but, based on my experience with the board, I would say that the following events happen:

  • if the application is functional and running, everything is fine, you can generally reflash it
  • if there is something wrong with the application, it generally throws an exception and hangs
  • for reasons that I do not know, OpenOCD is not able to halt the board immediately after reset, so the board starts and hangs with an exception
  • again for reasons I do not know, the debug code in OpenOCD does not seem able to get the board out of this hanged status

The usual/expected JTAG behaviour is that the debugger should be able to get full control of the debugged device, regardless the status reached, even with a faulty software. Unfortunately the RISC-V OpenOCD I used was not able to do this with the FE310 device; I reported this to SiFive, but I did not receive a good explanation.

A good question is why applications hang; well, in my case it was due to bugs in my under development code, which sometimes failed to start properly. Special attention must be observed to the startup code, to the linker script, and to the _sbrk() implementation, which depends on both; all can easily lead to hanged boards.

Another reasons for hanged devices, if you used the SiFive toolchain, is the mandatory inclusion of libgloss which implements system calls with ECALL; for example, if your application includes a printf(), but you missed to properly define _write(), the default call is implemented with an ECALL, which obviously fails. This problem was also reported to SiFive, but the toolchain configuration was not changed (the problem was fixed only in GNU MCU Eclipse RISC-V Embedded GCC).

As a conclusion, if you want to use the HiFive1 board, use the Arduino environment. My experience is that the board is generally not suitable for active development outside the Arduino development.

1 Like

I have a tendency to do a cost analysis on these sort of events in life and if I am sinking tens of hours of my time into something that isn’t really worth my time then that process gets ended right quick. It is a cute little board and yes there is a RISC-V processor there. I have never seen it do anything other than flash an led. However, there it is. Cute. Also back in the box and of no more interest to me. At some point in the future there may be a systemboard which is more reasonable and which can run Debian linux without any major hassle. I can wait.

Dennis, I’m sorry you’re frustrated, but it’s hard to understand your symptoms unless you actually have faulty hardware, whether the board itself (quite unusual, but of course possible), your USB cable, or your PC or USB port.

The boards do actually work! I use them every day.

It’s true that faulty programming can lock it up so OpenOCD can’t talk to it unless you take advantage of “safe mode” in the bootloader (press reset twice) but I’ve never seen a case where that doesn’t work, assuming the user hasn’t blown away the bootloader, which you can’t do unless you deliberately work at it. (The bootloader is at 0x2000_0000, while user programs are loaded to 0x2040_0000)

Liviu may well have done more low-level poking around on the HiFive1 than I have, but I’ve done a little bit … for example this, 18 months ago to the day, long before I had the idea to join SiFive…

I do however agree with Liviu that it’s best to stick to the Arduino environment and libraries, at least at first. Once you get things working you can incrementally replace Arduino library calls such as digitalWrite() with manipulating the device registers yourself.

1 Like

Bruce, could you check if the current documentation mentions this? If not, I suggest you talk to your colleagues and update the manual to explicitly request not to override the bootloader.

Initially I was tempted to do so, and I’m glad I did not, since this is a guaranteed path to brick the board for good.

FYI, in addition to the problems mentioned in the previous message, the FE310 device on the HiFive1 board has another problem, the usual double reset approach used by the Eclipse plug-ins to debug all other boards does not work, and the second reset must be disabled (the first reset is used before writing the device flash, the second reset is used before execution to start with a clean slate). I don’t know why it does not work, and SiFIve could not explain either, my guess was that it is interfearing with to the bootloader, thus the (bad) idea to remove it.


p22 “HiFive1 Boot Sequence”. If you’ve read this then the dangers of replacing the bootloader with other code not containing some similar mechanism are obvious.

I don’t think this document has ever changed.

At no point did I ever replace the bootloader nor attempt to do anything remotely fancy. What I did, exactly and precisely, was to follow the steps in the “Getting Started” guide wherein I did a git clone and then build of the source base. Quite a large one. I was happy to see gcc 8.1.0 in there as well as all the cross platform bits that one would seem to need. I was perfectly able to compile example code. I did carefully check the config file needed for communications with the board. I made one small change to the Makefile for dhrystone and that was merely to add a “-v” so that I can see verbose output of everything the compiler was doing. Seems to work fine and when compile was done ( 0.53 secs ) I had an output executable ELF file with the correct looking ELF Magic : 7f 45 4c 46 01 01 01 … etc which is a 32-bit little endian ELF file for RISC-V. Yay. Celebrations everywhere … take a sip of coffee and move onwards to the next step which bricked the board.

Here is a dry-run :

charon $ make --dry-run upload PROGRAM=dhrystone BOARD=freedom-e300-hifive1
work/build/openocd/prefix/bin/openocd -f bsp/env/freedom-e300-hifive1/openocd.cfg & \
/usr/local/riscv/freedom-e-sdk/work/build/riscv-gnu-toolchain/riscv64-unknown-elf/prefix/bin/riscv64-unknown-elf-gdb software/dhrystone/dhrystone --batch -ex "set remotetimeout 240" -ex "target extended-remote localhost:3333" -ex "monitor reset halt" -ex "monitor flash protect 0 64 last off" -ex "load" -ex "monitor resume" -ex "monitor shutdown" -ex "quit" && \
echo "Successfully uploaded 'dhrystone' to freedom-e300-hifive1."

That last line is a pure lie as nothing was ever uploaded to the hifive1 but the “echo” is stuck in the script anyways.

The actual command uttered and the output seen was thus :

$ make upload PROGRAM=dhrystone BOARD=freedom-e300-hifive1
work/build/openocd/prefix/bin/openocd -f bsp/env/freedom-e300-hifive1/openocd.cfg & \
/usr/local/riscv/freedom-e-sdk/work/build/riscv-gnu-toolchain/riscv64-unknown-elf/prefix/bin/riscv64-unknown-elf-gdb software/dhryst
one/dhrystone --batch -ex "set remotetimeout 240" -ex "target extended-remote localhost:3333" -ex "monitor reset halt" -ex "monitor 
flash protect 0 64 last off" -ex "load" -ex "monitor resume" -ex "monitor shutdown" -ex "quit" && \
echo "Successfully uploaded 'dhrystone' to freedom-e300-hifive1."
Open On-Chip Debugger 0.10.0+dev (2018-08-02-02:13)
Licensed under GNU GPL v2
For bug reports, read
adapter speed: 10000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description 'Dual RS232-HS', serial '*' at bus location '*'

Warn : Flash driver of onboard_spi_flash does not support free_driver_priv()
localhost:3333: Connection timed out.
"monitor" command not supported by this target.
"monitor" command not supported by this target.
You can't do that when your target is `exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.
Successfully uploaded 'dhrystone' to freedom-e300-hifive1.

So like I say … did one thing and one thing well and the board is a brick.


Just wondering - is this of any relevance here?


I don’t think my experience is relevant to this thread. I had a bootloader - it was just a buggy one that jumped to the wrong address. I was able to replace one bootloader (the one with the bug, which also was based on the blink test rather than the double-reset one) with another (the intended default double-reset one).