New HiFive cannot connect to console over usb

I just received my HiFive1 board and see both power LEDs on and I can see the device with lsusb:

Bus 001 Device 017: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC

The device also seems to be recognized by the OS (Debian 9.4) per /var/log/messages:

May 30 00:40:49 LinByte kernel: [ 8399.399743] usb 1-2: new high-speed USB device number 18 using xhci_hcd
May 30 00:40:49 LinByte kernel: [ 8399.540496] usb 1-2: New USB device found, idVendor=0403, idProduct=6010
May 30 00:40:49 LinByte kernel: [ 8399.540501] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
May 30 00:40:49 LinByte kernel: [ 8399.540505] usb 1-2: Product: Dual RS232-HS
May 30 00:40:49 LinByte kernel: [ 8399.540508] usb 1-2: Manufacturer: FTDI
May 30 00:40:49 LinByte kernel: [ 8399.541666] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
May 30 00:40:49 LinByte kernel: [ 8399.541740] usb 1-2: Detected FT2232H
May 30 00:40:49 LinByte kernel: [ 8399.542082] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
May 30 00:40:49 LinByte kernel: [ 8399.542321] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected
May 30 00:40:49 LinByte kernel: [ 8399.542386] usb 1-2: Detected FT2232H
May 30 00:40:49 LinByte kernel: [ 8399.542591] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB1
May 30 00:40:49 LinByte mtp-probe: checking bus 1, device 18: “/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2”

However, when I attempt to connect using ‘screen /dev/ttyUSB1 115200’ screen connects and shows no output. Unplugging the USB cable terminates screen. Clicking the reset button doesn’t appear to do anything (there is no flash of the LED after 1 second).

I’ve tried different cables, ports and computers with the same result.

There is no jumper on the IOREF pin header but per the getting started guide it sounds like the jumper is only needed if using the IO headers.

Any thoughts on what I’m missing or whether I should conclude the board is simply not working?

Getting output back can sometimes be problematic on a PC you haven’t used before. Even if you’ve followed the instructions with the /etc/udev configuration.

Can you download new programs?

Assuming you haven’t flashed a new program the colour LED should be cycling through different colours – this is the led_fade demo program.

If you load another demo such as dhrystone then the LED won’t do that:

freedom-e-sdk$ make software PROGRAM=dhrystone
freedom-e-sdk$ make upload PROGRAM=dhrystone

If you put led_fade back on then the LED should cycle:

freedom-e-sdk$ make software PROGRAM=led_fade
freedom-e-sdk$ make upload PROGRAM=led_fade

I’m not a big fan of using “screen” for interacting with the HiFive1. Usually I use the terminal in the Arduino IDE – open any sketch (don’t run it) and choose Tools/Serial Monitor. A simple “cat /dev/ttyUSB1” can also work if you don’t need to type input to the HiFive1 program (only after one of the others has set up the baud rate?).

Rebooting your PC can also help (sacrilege with Linux, I know…).

You could also see whether running programs in the Arduino IDE works.

Thanks Bruce. I tried cat as well as gtkterm and neither resulted in any output. I also cannot upload any programs as I get an error from openocd that it cannot find ftdi.

However, I did try the Arduino IDE as you suggested and I am able to successfully run blink. So, the board itself seems to be fine. Thanks!

You initial lsusb results show that the device is there and recognised by the ftdi driver in the kernel. So what’s left is things like permissions problems, not having added the user to the plugdev group etc.

I’m glad the board works for you via Arduino. It should work via both :slight_smile:

It seem like I have a similar issue like Mike and I suspect that the demo program somehow got lost.

When I connect my board my Ubuntu 16.04 does detect ttyUSB0 and ttyUSB1, and these devices are in the plugdev group and I have added my user to this group too. But when I connect to ttyUSB1 with minicom as root I do not get any boot loader banner or any output from the demo-program, which I had hoped for.

I have tried the arduinoIDE too, to see if I can get any response from the boot-loader, but no luck.

Is there any simple trick that I can do, to confirm that my board’s boot-loader are OK?

1 Like

Have you tried turning your computer off and on again?

Yes, I know this is Linux and it shouldn’t be necessary.

Nevertheless, it’s made things work for me on several machines where I’d done everything according to what should be necessary and it still didn’t work.

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 https://github.com/sifive/freedom-e-sdk.git
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/flash.lds b/bsp/env/freedom-e300-hifive1/flash.lds
index 6b37141..faa9c65 100644
--- a/bsp/env/freedom-e300-hifive1/flash.lds
+++ b/bsp/env/freedom-e300-hifive1/flash.lds
@@ -4,7 +4,7 @@ ENTRY( _start )
 
 MEMORY
 {
-  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:

2 Likes

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:

Thx!

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

USB:
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/flash.lds

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: