Error loading programs: `Error: Target not examined yet`

[gkelly]

I have a LoFive R1 and am trying to follow the instructions for using the new SDK. When I get to the programming step the program upload always fails.

The following is from me trying to run:

make PROGRAM=lofive-boot TARGET=lofive-r1-bootloader upload

If I don't press the reset button first:

scripts/upload --elf /home/gkelly/sandbox/freedom-e-sdk/software/lofive-boot/debug/lofive-boot.elf --openocd openocd --gdb riscv64-unknown-elf-gdb --openocd-config bsp/lofive-r1-bootloader/openocd.cfg
Open On-Chip Debugger 0.10.0+dev-00823-g20804cb4d (2019-10-30-23:00)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
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: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Info : datacount=1 progbufsize=16
Error: unable to halt hart 0
Error:   dmcontrol=0x80000001
Error:   dmstatus =0x00030c82
Error: Fatal: Hart 0 failed to halt during examine()
Info : Listening on port 3333 for gdb connections
Error: Target not examined yet

localhost:3333: Connection timed out.
"monitor" command not supported by this target.
"monitor" command not supported by this target.
You can't do that when your target is `exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.

If I do press the reset button first:

scripts/upload --elf /home/gkelly/sandbox/freedom-e-sdk/software/lofive-boot/debug/lofive-boot.elf --openocd openocd --gdb riscv64-unknown-elf-gdb --openocd-config bsp/lofive-r1-bootloader/openocd.cfg
Open On-Chip Debugger 0.10.0+dev-00823-g20804cb4d (2019-10-30-23:00)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
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: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Info : Listening on port 3333 for gdb connections
Error: Target not examined yet

localhost:3333: Connection timed out.
"monitor" command not supported by this target.
"monitor" command not supported by this target.
You can't do that when your target is `exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.

Here's the openocd invocation when run with -d: logs

This seems to point to riscv013_halt_go(): unable to halt hart 0. Unclear why it can't halt the HART. I tried both with the riscv-openocd from the sifive site and built from the riscv-openocd github repo.

Any debugging hints?

[mwelling]

Looks like there is an open issue with riscv-openocd. https://github.com/riscv/riscv-openocd/issues/195

Has this board programmed successfully in the past?

In the past, I was able to get fresh boards to program by manually pressing the reset just before running the openocd command but it took a few tries some times.

[riktw]

I have the exact same problem, I ordered two boards from Digi-Key and really wanted to work with them the weekend, but if I cannot load a program that is going to be quite difficult.

I am using the following versions: Open On-Chip Debugger 0.10.0+dev-00822-g0409bf9b2 (2019-10-18-23:08) GNU gdb (SiFive GDB 8.3.0-2019.08.0) 8.3

Both the latest from the SiFive website.

Pressing reset just before running the openocd command did not help.

[gkelly]

I have the exact same problem, I ordered two boards from Digi-Key and really wanted to work with them the weekend, but if I cannot load a program that is going to be quite difficult.

I am using the following versions: Open On-Chip Debugger 0.10.0+dev-00822-g0409bf9b2 (2019-10-18-23:08) GNU gdb (SiFive GDB 8.3.0-2019.08.0) 8.3

Both the latest from the SiFive website.

Pressing reset just before running the openocd command did not help.

Mine is also from Digi-Key. @mwelling which versions of the toolchain bundles are you using?

[gkelly]

Looks like there is an open issue with riscv-openocd. riscv/riscv-openocd#195

Has this board programmed successfully in the past?

Sorry, forgot to respond to this part. No, this is my first time trying to program this board.

In the past, I was able to get fresh boards to program by manually pressing the reset just before running the openocd command but it took a few tries some times.

I was trying that too, thinking that maybe I needed to catch it before it had changed the pinmux to take JTAG off of the pins. That's how I ended up with the two different behaviors in my original issue post.

[mwelling]

I will have to find a fresh LoFive to see if I can replicate and fix this issue.

[mwelling]

So I have been able to replicate this issue on the LoFive R1 with a fresh module.

I think I originally programmed the ones I had here with the old SDK so that is why I never ran into this issue when updating the bootloader to the new one.

Once the board has a program installed on the flash it works just fine.

Let me dig into OpenOCD and see if I can fix this.

[mwelling]

@gkelly What distribution / version of Linux are you using?

I found that the prebuilt Ubuntu toolchain was causing the issue on my computer. I am using Debian 10 and it does not have libncurses5 by default and the gdb instance was failing to launch.

make PROGRAM=lofive-boot TARGET=lofive-r1-bootloader upload
scripts/upload --elf /home/michael/projects/freedom-e-sdk/software/lofive-boot/debug/lofive-boot.elf --openocd /home/michael/toolchains/riscv-openocd-0.10.0-2019.08.2-x86_64-linux-ubuntu14/bin/openocd --gdb /home/michael/toolchains/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb --openocd-config bsp/lofive-r1-bootloader/openocd.cfg
/home/michael/toolchains/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory
make: *** [Makefile:343: upload] Error 127

Once I installed the legacy libncurses5, I was able to program the board.

[mwelling]

Maybe that was a fluke. I went back and erased the flash and now it won't program again.

[mwelling]

Okay try pulling the latest changes on the lofive-r1 branch of the mwelling/freedom-e-sdk. https://github.com/mwelling/freedom-e-sdk/commit/015f64ab090a2205002408aa6065b359651b76e7

See if that fixes the issue for you. If it doesn't work the first time, press the reset button and try again.

If you still can't get it to work send me the debugging output from openocd.

[riktw]

Here is my log, still some issues: https://pastebin.com/ve7qyj1H

What version of OpenOCD are you using?

[mwelling]

I am using the latest version provided on the SiFive website.

https://static.dev.sifive.com/dev-tools/riscv-openocd-0.10.0-2019.08.2-x86_64-linux-ubuntu14.tar.gz

[mwelling]

Provide the output of the console from the launching of the programming command.

I want to make sure that the gdb instance is running as well.

[riktw]

Ah sorry, the previous log was OpenOCD only. I now added the -d flag to the upload script so I can use the "make PROGRAM=lofive-boot TARGET=lofive-r1-bootloader upload" command and get a complete log with OpenOCD and GDB: https://pastebin.com/gJahf10H

[mwelling]

Does pressing the reset button before starting the upload help?

[riktw]

The result remains the same. I tried a few times, pressing the reset button just before, during or a few seconds before upload..

[mwelling]

Can you try with the prebuilt versions of openocd and the toolchain provided here so we can make sure that we have the same setup?

https://www.sifive.com/boards

See "Prebuilt RISC‑V / GCC Toolchain and Emulator" section.

[riktw]

I am already using the latest binaries from there. I am going to see if I can find a J-Link somewhere, as the Hifive board with the G002 chip uses an on board J-Link. Perhaps that helps getting these programmed.

[mwelling]

Yeah JLink supports this SoC as well. Sorry this is being so difficult.

https://wiki.segger.com/GroupGets_LoFive_R1_1

[psherman42]

The dreaded messages Error: unable to halt hart 0 Error: Fatal: Hart 0 failed to halt during examine() and Error: Target not examined yet have to do with a subtle difference between the HiFive and the LoFive boards: With the latter, input bias current on the EN input of the 1.8v regulator is too high, not allowing sufficient time for a solid reset.

Pushbutton SW1 (and JTAG TRST) triggers the AON_ERST_N non-maskable interrupt input. All well and good, so far.

Default programming in the Mask ROM for the PMUWAKEUP state machine provides moderate 16 cycle delay, and thus pulse width, for the AON_PMU_OUT_0 output.

RC combination of 150K Ohms and 10 uF (R4, C17 on LoFive; R32, C22 on HiFive) attempt to provide ~670 mS delay for the reset pulse.

However, this is where the problem lies: HiFive U8 is a RT9080-18GJ5 device whose EN input bias current is less than 0.1 uA. LoFive U4 is an SPX3819M5-L-1-8 device whose EN input bias current is around 3 uA and can be as high as 20 uA.

In other words, on the LoFive board, regardless how long the pushbutton SW1 (or JTAG TRST) is held, the output pulse from the PMU of the AON block simply never makes it down to low enough level to momentarily turn OFF the 1.8v supply -- thus, the CPU never resets.

The only recourse is complete removal of the 5V power or momentarily shorting across C17 with a tweezer (which won't hurt the AON_PMU_OUT_0 output because R4 150 K Ohm is such a high impedance). Either reducing the RC time constant (lowering values of R4 and/or C17) or selecting a 1.8v regulator with lower EN input bias current is suggested as a longer term solution.