Not able to upload programs expect in safe boot mode


(Quey-Liang Kao) #1

Hi,

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.


(Bruce Hoult) #2

Have you changed the clock speed at all? Does it work at 16 MHz in the Arduino IDE?


(Quey-Liang Kao) #3

Thanks for your reply.

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.


(Megan A. Wachs) #4

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).

  • You could try reducing the adapter speed (in freedom-e-sdk/bsp/env/freedom-e300-hifive1/openocd.cfg) : https://github.com/sifive/freedom-e-sdk/blob/master/bsp/env/freedom-e300-hifive1/openocd.cfg#L1

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 reporting this!
Megan


(Quey-Liang Kao) #5

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).

Yes. It’s a new cable.

You could try reducing the adapter speed (in freedom-e-sdk/bsp/env/freedom-e300-hifive1/openocd.cfg) : https://github.com/sifive/freedom-e-sdk/blob/master/bsp/env/freedom-e300-hifive1/openocd.cfg#L1

I tried 5000 kHz and 1000kHz, but it seems no effect. The output remains like the fail log above.

I hope the information helps, thanks!


(Bruce Hoult) #6

I believe @mwachs5 meant the output on USB serial when you run the program. e.g.

In your console:

 bruce:~/freedom-e-sdk$ make upload PROGRAM=led_fade

On USB serial (e.g. in GNU screen or etc as described in “Getting started”

core freq at 263156531 Hz

                SIFIVE, INC.

         5555555555555555555555555
        5555                   5555
       5555                     5555
      5555                       5555
     5555       5555555555555555555555
    5555       555555555555555555555555
   5555                             5555
  5555                               5555
 5555                                 5555
5555555555555555555555555555          55555
 55555           555555555           55555
   55555           55555           55555
     55555           5           55555
       55555                   55555
         55555               55555
           55555           55555
             55555       55555
               55555   55555
                 555555555
                   55555
                     5

               'led_fade' Demo 



55555555555555555555555555555555555555555555555
5555555 Are the LEDs Changing? [y/n]  555555555
55555555555555555555555555555555555555555555555
y
PASS

The first line above.


(Quey-Liang Kao) #7

Thanks for your tips.

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
...

(Megan A. Wachs) #8

Thanks for all your answers!

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.


(Bruce Hoult) #9

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 ?


(Megan A. Wachs) #10

Good point. I need to double check that it would still work.


(Megan A. Wachs) #11

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

(Quey-Liang Kao) #12

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.