New HiFive cannot connect to console over usb

While I’ve found minicom to be as stable as screen, you might just want to try screen to see if there’s a transient problem w/ your minicom setup:

screen /dev/ttyUSB1 115200

And… Hmm… I thought the HiFive1’s were pre-programmed with the LED_FADE demo program. So in addition to seeing a SiFive logo and “PASS” on the serial port, one of the LEDs should be slowly cycling through it’s color range.

But if the ttyUSB device files are there, at least the USB interface is working. You could re-program it and see if it works; after downloading the freedom-e-sdk, it should be pretty straight-forward to upload the LED_FADE program, check to see if there are any errors from OpenOCD and then verify you’ve got a blinking LED.

The process would look something like this:

# Clone the freedom-e-sdk repo
git clone
cd freedom-e-sdk
git submodule update --init --recursive

# Make the tool chain
make tools

# Make the LED_FADE program
make software BOARD=freedom-e300-hifive1 PROGRAM=led_fade

# Upload the program
make upload BOARD=freedom-e300-hifive1 PROGRAM=led_fade

If this process works, then yay! If not, it should help diagnose what the problem is.

Please try both ttyUSB0 and ttyUSB1. Sometimes the serial console gets mapped to ttyUSB0 and sometimes it gets mapped to ttyUSB1, so you have to try both.

I received my Hifive1 yesterday (ordered back in March) and I have the same problem. When I power it on the user LEDs don’t flash and there is no output on ttyUSB1 (or ttyUSB0). Perms on the PC side are fine, screen can open the device.

Is it possible that a batch of boards shipped without the demo program loaded into flash?

Also I can successfully upload the demo_gpio program, and it flashes the LEDs… but as soon as I reset the board it goes back to doing nothing, and the flash reads as all 0xffffff. As if it never stored the program. Not sure if I am doing something wrong there…

Oh, I see… I think I have the same problem as in this thread:

The OTP memory jumps to 0x20000000, which is supposed to contain the boot loader which jumps to the user program at 0x20400000. Using gdb I can see that the demo_gpio program is indeed flashed happily at 0x20400000, but the start of flash at 0x20000000 where the boot loader should be just reads 0xffffffff. There is no boot loader.

I guess that explains why the program will run once after I flash it, because gdb leaves it running from the program start address… but after I reset it the board goes back to doing nothing.

So, is it possible that some boards shipped without the boot loader flashed at 0x20000000? I’m pretty sure I didn’t accidentally erase it…

No bootloader at 0x20000000 from the factory/CrowdSupply is obviously a theoretical possibility. And unexpected and unfortunate, if so. That seems to be three of you now. No, four, including the other thread.

Here’s how I fixed it (I guess @DrItanium did the same thing), just in case anyone else finds this thread because they have the same issue…

I found this old thread about the boot loader source:

which is at software/double_tap_dontboot/double_tap_dontboot.c in the SDK.

I tweaked the linker script and gdb flashing script as hinted in that old thread, to make the program be flashed at 0x20000000 instead of the usual 0x20400000:

diff --git a/Makefile b/Makefile
index 6b8e1c6..dfad2fb 100644
--- a/Makefile
+++ b/Makefile
@@ -218,7 +218,7 @@ GDB_UPLOAD_ARGS ?= --batch
 GDB_UPLOAD_CMDS += -ex "set remotetimeout 240"
 GDB_UPLOAD_CMDS += -ex "target extended-remote localhost:$(GDB_PORT)"
 GDB_UPLOAD_CMDS += -ex "monitor reset halt"
-GDB_UPLOAD_CMDS += -ex "monitor flash protect 0 64 last off"
+GDB_UPLOAD_CMDS += -ex "monitor flash protect 0 0 last off"
 GDB_UPLOAD_CMDS += -ex "load"
 GDB_UPLOAD_CMDS += -ex "monitor resume"
 GDB_UPLOAD_CMDS += -ex "monitor shutdown"
diff --git a/bsp/env/freedom-e300-hifive1/ b/bsp/env/freedom-e300-hifive1/
index 6b37141..faa9c65 100644
--- a/bsp/env/freedom-e300-hifive1/
+++ b/bsp/env/freedom-e300-hifive1/
@@ -4,7 +4,7 @@ ENTRY( _start )
-  flash (rxai!w) : ORIGIN = 0x20400000, LENGTH = 512M
+  flash (rxai!w) : ORIGIN = 0x20000000, LENGTH = 512M
   ram (wxa!ri) : ORIGIN = 0x80000000, LENGTH = 16K

and then built and flashed it:

$ make software PROGRAM=double_tap_dontboot BOARD=freedom-e300-hifive1
$ make upload PROGRAM=double_tap_dontboot BOARD=freedom-e300-hifive1

and now the boot loader works the way it’s supposed to. :slight_smile:


Thanks @danc. I think we’re going to have to distil this to a simple script anyone can copy&paste. If we’ve really got a rogue batch of boards going out then there could be a lot more people not as savvy as you and @DrItanium

I had to resolve the openocd error “Error: The specified debug interface was not found (ftdi)” first. After reviewing the configure output it was obvious I was missing libftdi-dev and libusb-1.0.0-dev (on Debian 9.4). After adding those libraries and rebuilding openocd the error went away.

Then I followed @danc’s post to install the bootloader, reverted the changes, built and installed led_fade. Resetting the board with cat </dev/ttyUSB1, screen, gtkterm, minicom all show the expected SiFive logo as well. Yay. :slight_smile:


Thanks for the report. Glad you got it going.

@erasmussen1 have you been able to get it working?

Yes, I finally my Ubuntu 16.04 to talk to the board.
Just to summarize what I had to do, in case someone else has this issue:

I had two issue:

  1. The board didn’t have led_fad installed, based on the fact that color RGB LED was not changing colors)
  2. I didn’t get any response/output in minicom

Make sure that libusb-1.0.0 is installed:
sudo apt-get install libusb-1.0-0-dev

Then build the freedom-e-sdk tools

Change the flash start address to 0x20000000 in file bsp/env/freedom-e300-hifive1/

and in the Makefile change this line to GDB_UPLOAD_CMDS += -ex "monitor flash protect 0 0 last off

then build the led_fad demo app:
make software BOARD=freedom-e300-hifive1 PROGRAM=led_fade

and then upload the app to the board:
sudo make upload BOARD=freedom-e300-hifive1 PROGRAM=led_fade

Now when I start minicom:

minicom -D /dev/ttyUSB1

and press ‘y’ the board responds back with “PASS”

and the rgb led is changing color

I’m glad you got it going. However what you’ve done is upload the app to the area where the bootloader should be. That works but probably isn’t long term optimal :slight_smile:

Thanks for pointing it out.
That means that my board somehow didn’t have the boot-loader.
Thanks for your help, my next step is to get the boot-loader back on the board.

I escalated this a couple of days ago and SiFive contacted Crowdsupply in the weekend and they’re hopefully taking steps to find the extent of the problem and prevent it happening to more customers.

My first board arrived today. I can confirm the same symptoms from Mac and using Arduino IDE. USB connection lights 5V and 3.3V LEDs. No color-cycling RGB LED. No response on either USB/serial connection (via IDE console). No red LED on safe-boot via RESET double-click.

I’d be happy to beta-test your “simple” recovery script/procedure :wink:

Hi Dale, sorry about that. Do you want to do what the others here have done in the meantime, or wait for a more official solution?

If you don’t have the boot-loader but just go straight to the app, and the app is buggy, you can brick the board enough that JTAG is the only way to recover.

Is it possible to fix the bootloader from Freedom Studio?

Hi Bruce and thanks for your help. I managed to install the boot where it should be, and now it loads the led_fade program from the right address (0x20400000) and I now see the banner at startup and then I see the led changing color. Again, thanks for you help.


1 Like

How about if the bootloader finds itself loaded at 0x20400000, it relocates itself to 0x20000000? That way any of the standard tools to load a program will work to load/repair a new bootloader.

That doesn’t work, because in that case the bootloader would need to contain code to program the flash which is quite a complex process.