Debug RAM application for QN9030

[EmilS]

Building an application for RAM is straight forward: Under the Settings/Linker/"Managed Linker Script" tab check "Plain load image"->SRAM. This will produce an .axf (ELF) file with all the addresses in RAM.

When you try to debug this file you get a busfault. This is to be expected since the interrupt vector table is not at the default address. In the past I've used an OnSemi/RSL10 part which has an IDE also based on Eclipse. To debug a program in RAM I had to add

set {int} &__VTOR = ISR_Vector_Table;

set $sp = *((int *) &ISR_Vector_Table)

in the RunCommands field for J-Link debug.

I can debug my QN9030 RAM application if I add

arm-none-eabi-objcopy -v -O ihex --change-addresses 0x04000000 "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.hex"

to generate an iHex file and then run JLinkExe and manually load the hex file, set the IVT, MSP and start point and then run it. This only allows me to debug in assembler with no references to my source C code.

What do I need to do to debug a RAM application from the Eclipse IDE?

[EmilS]

I was hoping that I can set the IVT from within mcuxpressoide or with a little script but I couldn't find how to do this.

My application must reside entirely in RAM because I plan to use it in production when the parts are blank. It uses the J-Link RTT (and the J-Link SDK for the host side) to transfer the data payload and then the RAM application programs both the flash and an external quad-SPI flash and finally locks the part. I've done this in the past with an OnSemi part and it works well, fast and reliably.

I have workarounds for this problem but it is not as convenient as to debug the application in RAM.

[mario_castaneda]

Hi @EmilS,

I am really sorry. Just to confirm, Do you want to load a RAM application as a secondary bootloader, and then use the RAM application to load Flash/QSPI Flash data, am I right?

For QN9030, it's not possible to boot from RAM directly. The application should run the secondary bootloader in flash and assign some functions to RAM.

Regards,

Mario

[EmilS]

> For QN9030, it's not possible to boot from RAM directly. The application should run the secondary bootloader in flash and assign some functions to RAM.

It _is_ possible to run an application in RAM directly using a J-Link a script like this:

device QN9030
si SWD
Speed 4000
connect
r ; reset
halt
loadfile qn9030_pgm.hex
w4 0xE000ED08,0x4000000 ; set IVT
wreg MSP,0x4015FE0 ; set StackPt
SetPC 0x4000135
g
qc

This will set the IVT, stack pointer and start address then run the application.

The only thing not possible is to debug a RAM application from mcuxpressoide with J-Link

(and that's only because there is no mechanism to send instructions to the J-Link probe at load time).

[mario_castaneda]

Hi @EmilS,

We are checking if there is a way for a better implementation

As a workaround, you can debug the application in flash during the developing stage. And then move to RAM in the product stage.

Regards,

Mario

[EmilS]

That is precisely what I was doing but my application programs the flash so I have to be careful what regions I erase and program.

[mario_castaneda]

Hi @EmilS,

The QN9030 needs to boot from reading out the ROM code, in this case you could develop in flash.

Sorry for any inconvenience that this may cause you.

Regards,

Mario

[mario_castaneda]

Hi @EmilS,

I understand the issue that you are facing. The QN9090 provides the Quad SPIFI for accessing an external flash device. I am checking this with the APP team and get back to you as soon as possible with some feedback.

Regards,

Mario

[mario_castaneda]

Hi @EmilS,

I am not sure of the process that you are following on Eclipse.

Did you try with the MCUXpresso IDE?

Regards,

Mario

[EmilS]

Maybe I wasn't very clear:

I am trying to debug a RAM application from within MCUXpresso IDE. When I start the debugging session, the application loads but then it busfaults (without me clicking anything). The application is small enough to fit entirely into RAM.

If I compile the same application for Flash and start a debug session then it stops normally on the first instruction in main().

I know that the RAM version is compiled correctly because I can debug it manually outside MCUXpresso using JLinkExe (but assembler only).

There is no option under J-Link Debugger to tell the server that the Interrupt Vector Table is now at address 0x4000000. How can I do that with J-Link?

The manual details the debug procedure in "RAM projects with LinkServer" but that's for a different debugging probe.

[mario_castaneda]

Hi @EmilS,

The issue that you have seems to be normal because you are running the code into the RAM, so the NVIC table for example is not defined correctly. you have to take care of this.

Please look at the next community post.

This is an example of the process that you want to achieve.

https://community.nxp.com/t5/i-MX-RT/iMXRT1052-Link-Application-to-RAM/td-p/1082503

Regards,

Mario

[EmilS]

The link you have sent doesn't help at all.

How do you set the IVT address?

Is it possible to debug RAM applications from within mcuxpressoide using a J-Link probe (Yes/No)?

[mario_castaneda]

Hi @EmilS,

How do you set the IVT address?

The ROM code of the application will jump to the flash application in this case. So, in this case, you can not modify the ROM code to jump to a different address. You could create a simple code in Flash to jump to RAM and debug your application.

Is it possible to debug RAM applications from within mcuxpressoide using a J-Link probe (Yes/No)?

Yes, but it will be part of your implementation.

Is there a specific reason why do you want to debug in RAM?

Regards,

Mario