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
git submodule update --init --recursive
# Make the tool chain
# 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.
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.
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.
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
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.