Third party build cannot be uploaded

[stnolting]

Third party build cannot be uploaded

[stnolting]

Hey there!

I used the settings you recommend like ilp32 ABI and rv32i in the IDE and used your linker and startup file also in the IDE.

That sounds good! I think the final executable should be able to run on the NEORV32. The question is just how to get it into the processor. 👍

I am not familiar with Segger's Embedded Studio. However, if you are using any compiler setup that does not use the provided scripts from the repository you need to generate the executable for the bootloader by yourself.

The executable's format is describe in chapter 📚 4.4. Executable Image Format of the data sheet.

You can use the commands from the central software makefile (sw/common/common.mk) to create a final binary from you programs ELF file. This binary is not the actual executable - it just contains all the program-related data so the processor can actually run it:

neorv32/sw/common/common.mk

Lines 157 to 161 in cc9a265

	main.bin: main.elf $(APP_ASM)
	@$(OBJCOPY) -I elf32-little $< -j .text -O binary text.bin
	@$(OBJCOPY) -I elf32-little $< -j .rodata -O binary rodata.bin
	@$(OBJCOPY) -I elf32-little $< -j .data -O binary data.bin
	@cat text.bin rodata.bin data.bin > $@

This final binary is then transformed into the actual executable (just adding a small header) using the "image generator" (sw/image_gen) for upload via the bootloader:

neorv32/sw/common/common.mk

Lines 169 to 171 in cc9a265

	$(APP_EXE): main.bin $(IMAGE_GEN)
	@set -e
	@$(IMAGE_GEN) -app_bin $< $@ $(shell basename $(CURDIR))

Another option is to use the JTAG interface of the on-chip debugger. Using gdb you can directly upload the main.elf file from your IDE (no need to create an explicit executable as the bootloader is not required at all for this setup):

• 📚 User guider: Debugging with GDB

[AbdulrahmanKH7]

I am trying to upload via gdb and I get this message at SiFive Freedom:

Open On-Chip Debugger
Target not examined yet
Error executing event gdb-attach on target neorv32.cpu.0:

Target neorv32.cpu.0 not examined yet, refuse gdb connection 1!
attempted 'gdb' connection rejected

I used your configuration file and also tried it with your approach on Linux and got the same message.
Of course I enabled the on-chip debugger.

At Embeddedstudio I get a timeout at port 3333 and I guess it's the same thing.

Best regards

[stnolting]

Can you run openOCD in something like a "stand alone mode" (so outside of the IDE / just in a console)? Then you can add the -d flag to enable debug outputs. Maybe there is a problem with your USB driver 🤔

neorv32/sw/openocd$ openocd -d -f openocd_neorv32.cfg

What kind of adapter are you using?

---

I am using the openOCD version from SiFive:

N:\Projects\neorv32\sw\openocd>openocd -f openocd_neorv32.cfg
Open On-Chip Debugger 0.11.0-rc1+dev (SiFive OpenOCD 0.10.0-2020.12.1)
Licensed under GNU GPL v2
For bug reports:
        https://github.com/sifive/freedom-tools/issues
1
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : JTAG tap: neorv32.cpu tap/device found: 0x0cafe001 (mfg: 0x000 (<invalid>), part: 0xcafe, ver: 0x0)
Info : datacount=1 progbufsize=2
Info : Disabling abstract command reads from CSRs.
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=32, misa=0x40901105
Info : starting gdb server for neorv32.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections

But I think any openOCD version should work as RISC-V has reached upstream support.

I am using a simple FTDI breakout board as JTAG adapter. The drivers are a little bit tricky when using Windows....

[AbdulrahmanKH7]

I am using ARM-USB-TINY-H adapter.
I will try to add the -d flag and see what happens
Many thanks 👍

[AbdulrahmanKH7]

By the way I changed the PID and VID and other parameters according to this adapter

[stnolting]

I am using ARM-USB-TINY-H adapter.

I have no idea about that, but if it provides a plain JTAG interface then it should work. 😉

By the way I changed the PID and VID and other parameters according to this adapter

👍
You should also start testing with a minimal JTAG clock speed: adapter speed 1000 (or even less if supported by the adapter)

[emb4fun]

Do you have still problems to get the blink_led examples running on "Segger Embedded Studio for RISC-V"?
I could successful get it to work. But you must have to use a J-Link.

Regards,
Michael

[AbdulrahmanKH7]

Do you have still problems to get the blink_led examples running on "Segger Embedded Studio for RISC-V"? I could successful get it to work. But you must have to use a J-Link.

Regards, Michael

Hi,
Thanks for reaching out. I tried with the J-link and it failed also. Do you use any special settings in the IDE?

[AbdulrahmanKH7]

I think my ARM-USB-TINY-H adapter does not support the J-link. What debugger adapter did you use?
Best regards

[emb4fun]

The Segger Embedded Studio works only with a J-Link.

[stnolting]

@AbdulrahmanKH7

The on-chip debugger's "debug transfer module" (the actual JTAG "PHY") has been reworked (#216) because there were some timing issues in the external interface. That's why the Jlink EDU could not connect to the chip. Maybe this was also the cause of your troubles with your debugger.

[stnolting]

I think this can be closed. Feel free to open another issue if you have further questions/problems.