Debug 1064 RT at 0x7002_0000, FreeRTOS, J-Link

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Debug 1064 RT at 0x7002_0000, FreeRTOS, J-Link

847 Views
Keith4DSmith
Contributor V

I’m using MCUxpresso 11.x for a 1064 RT project on the NXP 1064 RT eval board.

I can debug a program that starts at 0x7000_0000 with Segger J-Link (J47 and J48 disabled on eval board).

This is the configuration one would find for a bootloader. Using 2.6 SDK.

I want to build and debugger an application that starts at 0x7002_0000, a program the bootloader would start.

When I change MCU settings to specify 0x7002_0000 as a start address I notice that the .boot_hdr from /xip folder is not in the build (verified in map file).

In addition, I am using FreeRTOS.

In the JLink Debugger tab, I click on 'Initialize CPU Registers' and unclick 'Reset before running'. I am able to debug a program at offset 0x7002_0000.

If I check 'Select RTOS plugin' which enables GDBServer/RTOSPlugin_FreeRTOS, I can break at ResetISR, but I can’t seem to get past the watchdog code in SystemInit(). [DISABLE_WDOG = 1]

The J-link log shows retrieving the FreeRTOS information after loading the program. Log attached.

The 'failure' to debug a program not at the 'base' address and using FreeRTOS with J-Link has been a problem with 10.3 as well.

Some projects work. Some projects don't.

Labels (1)
0 Kudos
3 Replies

676 Views
jorge_a_vazquez
NXP Employee
NXP Employee

Hi Keith Smith

RT devices use the boot header to notify to the ROM code configuration about the memory from where it is booting, since mcuxpresso IDE doesn't add the header if the address doesn't match to the one used to program, it will not download anything.

I recommend you to leave the same address and create a function to jump to the address that you want to use.

Best regards

Jorge Alcala

0 Kudos

676 Views
Keith4DSmith
Contributor V

Looking at the .map file of an SDK example, 0x7000_0000 to 0x70000_1fff is occupied by .boot_hdr, the ROM code configuration data.

.isr_vector starts at 0x7000_2000. This would be the start address of a bootloader, or standalone program.

An application will have its .isr_vector at, say, 0x7002_0000. The bootloader performs a jump to 0x7002_0000 at the end of its startup.

When I build the application MCUxpresso with MCU settings PROGRAM_FLASH Location is not 0x7000_0000 .boot_hdr is not included in the build. As your comment suggests, I have to include a simple function to jump to 0x7002_0000

This simple function overwrites any bootloader that might be present. To then run without the debugger, the bootloader has to be reloaded along with the application. This suggests that the application has to have the bootloader included in its image.

I have been working with the K22 and Segger J-Link where I have a bootloader and application. I debug the application, stop the debug session, hit reset on the MCU and the bootloader runs the application. The application did not disturb the bootloader while it was being debugged.

Is there some application note or other document describing best practice for debugging applications in a bootloader environment running on an MCU with ROM code configuration (QSPI flash)?

0 Kudos

676 Views
jorge_a_vazquez
NXP Employee
NXP Employee

Hi Keith Smith

You could disable the "manage linker script" in the Setting options of the project and modify the linker file to keep the header boot in the 0x70000000 address and load your application to the offset that you require. This implies more modifications, but it is the ideal method for your scenario.

Regards

Jorge Alcala

0 Kudos