I bought two hifive1s. One was the early version, and the other board is a normal one. I just got the latter one and do some test with it. The result is somehow weird.
I success uploading the hello program to it, but then when I try any other programs, messages like
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 10000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (<unknown>), part: 0x0e31, ver: 0x1)
Error: Wrote 0xffe04493 to Debug RAM at 0, but read back 0xfff04493
Error: Debug RAM 0x0: 0xffe04493
Error: Debug RAM 0x1: 0x01f4d493
Error: Debug RAM 0x2: 0x40902023
Error: Debug RAM 0x3: 0x01f4d493
Error: Debug RAM 0x4: 0x40902223
Error: Debug RAM 0x5: 0x3f00006f
Error: Debug RAM 0x6: 0x060c1218
Error: Debug RAM 0x7: 0xf3efffff
Error: Debug RAM 0x8: 0x00000000
Error: Debug RAM 0x9: 0x00000000
Error: Debug RAM 0xa: 0x00000000
Error: Debug RAM 0xb: 0x00000000
Error: Debug RAM 0xc: 0x00000000
Error: Debug RAM 0xd: 0x00000000
Error: Debug RAM 0xe: 0x00000000
Error: Debug RAM 0xf: 0x00000000
Error: Target not examined yet
appears, and fails.
Getting into the safe mode does allow me to upload a new program, but then the same situation repeats, while the first hifive1 I got never showed these behaviors.
So I would like to know that how should I fix this problem? Is there more information you need to help me with this? Thanks.
I use the SDK directly and I donāt have an Arduino IDE.
What should I do to change the clock speed correctly? I have check the getting start guide and find nothing about clock speed.
Hmm, sounds like things are spotty on the debug/JTAG connection, it reports a 1 bit error but then reads the right thing later. This could be a clock speed issue, but letās try to get to the bottom of whatās going on. Bunch of questions for you, answer whatever youāre comfortable with.
If you upload a program in safe mode, does the program itself run successfully?
All the programs in the SDK boost the clock frequency to 256 kHz or so and print it over the UART. Iām curious what speed yours is at, can you see the message?
Is the error message always exactly the same? Is the 1-bit error always in the same place, or is it wrong in various ways?
You can prevent the SDK from boosting the clock frequency by adding ā-DNO_INITā while youāre compiling, by adding it to the programās Makefile (see https://github.com/sifive/freedom-e-sdk/blob/master/software/double_tap_dontboot/Makefile#L3 for an example). You could try adding that flag to freedom-e-sdk/software/led_fade/Makefile for example, and see if it impacts the ability to upload the next program.
are you using the same USB cable you were using before? Weāve noticed the boards are sensitive to older/flaky USB cables ( these from Amazon have a noticeably tighter fit than some others we had lying around the lab).
Let us know what youāre seeing and we can figure out whatās going on.
Quite frankly I am always pleasantly surprised when things work without the safe bootloaderā¦ I was planning to change the OpenOCD config to do the ādouble tapā itself to force the processor to be in a safe mode before it tries to reprogram, but until now it hasnāt proven to be necessary.
Thanks for your debugging questions and instructions. I will try to reply all of them below.
If you upload a program in safe mode, does the program itself run successfully?
Yes. hello, demo_gpio and some others are tested and OK.
All the programs in the SDK boost the clock frequency to 256 kHz or so and print it over the UART. Iām curious what speed yours is at, can you see the message?
Do you mean the line of Info: clock speed: 10000 kHz ? This log is shown when success,
and This log when it fails.
Is the error message always exactly the same? Is the 1-bit error always in the same place, or is it wrong in various ways?
There is always some line like Error: Wrote 0xffe04493 to Debug RAM at 0, but read back 0xfff04493. The 1-bit error remains.
You can prevent the SDK from boosting the clock frequency by adding ā-DNO_INITā while youāre compiling, by adding it to the programās Makefile (see https://github.com/sifive/freedom-e-sdk/blob/master/software/double_tap_dontboot/Makefile#L3 for an example). You could try adding that flag to freedom-e-sdk/software/led_fade/Makefile for example, and see if it impacts the ability to upload the next program.
It seems no effect adding this added flag.
are you using the same USB cable you were using before? Weāve noticed the boards are sensitive to older/flaky USB cables ( these from Amazon1 have a noticeably tighter fit than some others we had lying around the lab).
Some samples here (There is a pre-loaded hello example in the board, and I just push the reset several times):
core freq at 259601203 Hz
hello world!
Progam has exited with code:0x00000000
core freq at 258854092 Hz
hello world!
Progam has exited with code:0x00000000
core freq at 258811494 Hz
hello world!
Progam has exited with code:0x00000000
core freq at 258726297 Hz
hello world!
Progam has exited with code:0x00000000
core freq at 258939289 Hz
hello world!
Progam has exited with code:0x00000000
...
Iām still intrigued by this. We would of course be happy to just exchange your board (email info@sifive.com if you want to go that route), but that will mean a wait for you and Iām still wondering if there is something simple going on.
If youāre willing, could you try a few more things:
Can you make sure you have the latest versions of the tools? Especially for OpenOCD, we fixed several issues related to programming since the Founders Editions boards came out.
If you just reset your board (just hit the button once) and then reprogram it, do you still have the issue? Or you really must use the āsafeā loader?
Iām wondering if the -DNO_INIT flag was applied, as that will mean your board is running at ~16MHz instead of 260MHz when you try to reprogram it. Can you try applying the -DNO_INIT flag and then look at the output of āhelloā as you did before? You should NOT see the ācore freqā message.
I tried that and saw āhello world!ā without core freq header ā¦ once ā¦ and then when I reset the board I saw nothing. What serial settings do you get with -DNO_INIT ?
Ah, @brucehoult youāre right. If you add the -DNO_INIT flag, the uart_init() doesnāt get called. The message prints the first time because the settings are still set from your previously running code, but once you hit reset they get wiped out and arenāt restored.
But, I remembered that the led_fade demo actually sets the clock source back to the 16Mhz crystal and configures the UART itself. So @nonerkao can you reprogram without safe boot mode if the previous program was āled_fadeā:
make software upload PROGRAM=led_fade
(hit reset button just once)
make software upload PROGRAM=led_fade
If youāre willing, could you try a few more things:
Can you make sure you have the latest versions of the tools? Especially for OpenOCD, we fixed several issues related to programming since the Founders Editions boards came out.
Yes, I got stuck on this problem right after I updated the whole SDK.
If you just reset your board (just hit the button once) and then reprogram it, do you still have the issue? Or you really must use the āsafeā loader?
Both yes. The issue remains when simply resetting it. The safe loader is required.
But according to @brucehoult 's suggestion, using Arduino IDE with correct setup can somehow bypass the situation āsometimesā. I mean, a re-upload of those samples has roughly 50% chance to success.
Iām wondering if the -DNO_INIT flag was applied, as that will mean your board is running at ~16MHz instead of 260MHz when you try to reprogram it. Can you try applying the -DNO_INIT flag and then look at the output of āhelloā as you did before? You should NOT see the ācore freqā message.
The flag was not applied to the makefile of hello. After correctly apply the flag to both hello and led_fade, something interesting happens!
I found that after a successful upload, the next try must fail; after the fail, the next upload successes, for both sample program in any sequence.
I hope the information helps.
So @nonerkao can you reprogram without safe boot mode if the previous program was āled_fadeā:
make software upload PROGRAM=led_fade
(hit reset button just once)
make software upload PROGRAM=led_fade
The behavior of the board follows the rules I described above. Exact one of the consecutive uploads successes, no matter when to insert the reset.
Thanks for helping me for this. At least now I can reprogram it without the safe boot, just need a additional upload.