Question About Debugging A Direct Boot Application over JTAG

[mericozturk]

Hello!

I'm just getting started with this amazing project and am having a little trouble getting the JTAG working. My application is using "Direct Boot" and in that section it mentions

For this setup we do not want the bootloader to be implemented at all. Disable implementation of the bootloader by setting the INT_BOOTLOADER_EN generic to false. This will also modify the processor-internal IMEM so it is initialized with the executable during synthesis.

However in the JTAG section it states

This tutorial uses gdb to directly upload an executable to the processor. If you are using the default processor setup with internal instruction memory (IMEM) make sure it is implemented as RAM (INT_BOOTLOADER_EN generic = true).

Does this mean that I can't debug applications over JTAG if I'm using Direct Boot? Or is it only speaking to the ability to upload code through gdb, and breakpoint debugging is still supported in Direct Boot mode? Are there any caveats besides code upload when JTAG debugging in Direct Boot mode?

[GideonZ]

Hi Meric, Does this mean that I can't debug applications over JTAG if I'm using

Direct Boot? Or is it only speaking to the ability to upload code through gdb, and breakpoint debugging is still supported in Direct Boot mode? Are there any caveats besides code upload when JTAG debugging in Direct Boot mode?

In order for debugging to work, you will need to have *write access* to the location from where the program code is fetched. So, the program that you want to debug should reside in RAM for the locations to be writable. In general, you'd have a ROM section labeled 'bootloader', and an application that resides in RAM. This could either be IMEM or external DRAM, or whatever. Debugging code in ROM requires hardware breakpoints. This requires extra logic cells to match the program counter with a whole list of breakpoint addresses. For this reason, such an approach offers a limited number of breakpoints. AFAIK, NeoRV does not implement hardware breakpoints at this point. Message ID: ***@***.***>

…

[mericozturk]

Hi Gideon,

Appreciate your help! It sounds like as long as my IMEM is set up as RAM I should be able to debug direct boot applications over JTAG, does that sound right? I was trying to understand why the JTAG section suggests that INT_BOOTLOADER_EN must be enabled, I don't have a ROM bootloader in my application.

[stnolting]

In order for debugging to work, you will need to have write access to the
location from where the program code is fetched. So, the program that you
want to debug should reside in RAM for the locations to be writable. In
general, you'd have a ROM section labeled 'bootloader', and an application
that resides in RAM. This could either be IMEM or external DRAM, or
whatever.

Correct. Just a little addition here: for arbitrary breakpoints you'll need write access to the program memory. Halting, single-stepping and inspecting the processor state via gdb also works when executing the targeted program from ROM.

Debugging code in ROM requires hardware breakpoints. This requires extra
logic cells to match the program counter with a whole list of breakpoint
addresses. For this reason, such an approach offers a limited number of
breakpoints. AFAIK, NeoRV does not implement hardware breakpoints at this
point.

Actually, we do have trigger module that implement a single hardware breakpoint 😉

[stnolting]

Hey @mericozturk!

Does this mean that I can't debug applications over JTAG if I'm using Direct Boot? Or is it only speaking to the ability to upload code through gdb, and breakpoint debugging is still supported in Direct Boot mode? Are there any caveats besides code upload when JTAG debugging in Direct Boot mode?

You can also debug applications when using the direct boot setup. The problem here is that the debugger cannot insert arbitrary breakpoints. When using a RAM-based setup, the debugger temporarily (and transparently for the user) replaces instructions by "break" instructions for triggering the actual breakpoints. Obviously, this is not possible when running code from ROM.

However, the NEORV32 implements the RISC-V trigger module that implements a single hardware breakpoint. This allows to implement a breakpoint even when running code from ROM.

You can find some more information about this in the NEORV32 online documentation:

• documentation: 📚 NEORV32 trigger module
• user guide: 📚 using hardware breakpoints

[stnolting]

I got the JTAG up today and I guess I am running into the problem you are outlining-- with my direct boot application I am not able to use loadbin or otherwise write to the instruction address space, even though the IMEM region is implemented as block RAM in the FPGA fabric. I guess I was expecting this region to be writable since it is just RAM, but it seems like because neorv32 sees it as ROM it's executing out of I won't be able to use this approach to update just the application? Like using Direct Boot precludes you from writing to the IMEM regardless of what the underlying FPGA fabric is, does that sound right?

That is correct. The memory primitives provided by most FPGAs are RAM-based. However, there are some FPGAs (like Intel MAX10) that also provide some kind of ROM primitives (as part of the on-chip bitstream flash), which would perfectly reflect a "direct boot" scenario.

However, the "direct boot" concept is intended for designs that - for example - do not provide any mechanism to upload a program after programming the bitstream (for example because the on-chip debugger & UART are not implemented). Hence, the actual program code is "installed permanetly to the bitstream" resulting in a pre-initialized RAM without explicit write capabilities.

The only way to use something like loadbin is to set up the bootloader approach and configure neorv32 to execute out of RAM?

Basically, this is correct. But the terms "direct boot" and "indirect boot" only apply when using the default processor-internal IMEM and DMEM. Alternatively, you can customized your setup using external memories connected via the processor's bus interface. In that case, you have full freedom to decide on the boot process.

Thanks again! This project is amazing 💯

Thanks again! 😃

[mericozturk]

OK I think I get it! My application is actually already using external IMEM, MEM_INT_IMEM_EN=false so I'm currently using the 2b approach from Figure 4 and running into the loadbin problem with that setup. I want to continue bundling my firmware with my bitstream, but also have the ability to loadbin and set software breakpoints, so it seems like I should go to the 1b approach by enabling the bootloader and just modify it to jump directly into my pre-initialized IMEM instead of waiting around for an image over UART.

[stnolting]

OK I think I get it! My application is actually already using external IMEM, MEM_INT_IMEM_EN=false so I'm currently using the 2b approach from Figure 4 and running into the loadbin problem with that setup.

This is strange 🤔 The on-chip debugger does not care if it is using internal or external memory.

Maybe there is a problem with the interface and/or address mapping. If you have the internal IMEM disabled, you should "map" your external IMEM to the instruction space address (default 0x00000000).

I recommend to keep the internal memory for now and re-map your external one to something like 0x90000000. Then you could use the default UART bootloader (or the on-chip debugger) to upload the bus_explorer example program and use that to inspect your external memory's interface - just to make sure the interface/timing is fine.

I want to continue bundling my firmware with my bitstream, but also have the ability to loadbin and set software breakpoints, so it seems like I should go to the 1b approach by enabling the bootloader and just modify it to jump directly into my pre-initialized IMEM instead of waiting around for an image over UART.

Right, this might be the simplest approach.

I was thinking about adding another boot scenario with IMEM as RAM but without the bootloader. The bootloader would just be replaced by a simple endless loop so the CPU "halts" there until the on-chip debugger takes over.

[mericozturk]

Your instinct was right on, it turned out to be a problem with my IMEM bus! I am now able to initialize my external IMEM via bitstream, then debug in VSCode to my heart's content without having to mess with bitstreams anymore. Amazing!

[stnolting]

I'm glad to hear that! 😃 👍