How to debug bootloader code running on RAM

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

How to debug bootloader code running on RAM

10,217 Views
chfakhtchfakht
Contributor III

Hi,

I'm developing a bootloader for the MPC5748G in C.

The bootloader will be running on RAM so i want to know how can i debug the bootloader code running on the MPC Target.

I have the JTAG Debugger with trace32 software

 

Note: i'm just beginner

 

Thanks

Labels (1)
12 Replies

6,376 Views
chfakhtchfakht
Contributor III

Hi,

yes we can flash the 6Mb file directly but the final board will be packaged and the JTAG will not be accessible so in this case we need an application that accomplish some functionnal tests for the Hardware and then flash the final application using CAN or ETHERNET. (please tell me if it not clear now !)

Yes i'm sure that the UTEST area is not affected. The bus error was solved by using another batch script !

I can also generated an S19 file ...

So what about debugging the BTL code in RAM ?

thanks a lot

0 Kudos

6,376 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

first of all, if you want to copy a code to RAM, it must be compiled either as a PIC code (position independent code) or it must be compiled for RAM addresses. Or you have to write it in assembler and use relative addresses/jumps only. If you use PIC code, you will not see symbols/source files in debugger once the code is moved somewhere. Better way is to compile the code for RAM.

Then I can see two options:

1. Use two independent projects, so you have two elf files (s-record files). First one will be compiled for flash addresses as usual and it will just copy the second one to RAM. Second project will be compiled for RAM addresses.

Then you can load the symbols for RAM project using command:

data.load.elf your_file.elf /NOCODE

2. Second options is to use one project. Only needed functions are moved to RAM. Copy them, execute them, load new firmware and reset the device. You just can't jump back to flash. You have single elf file, so you can debug the code without any restrictions.

Lukas

6,376 Views
chfakhtchfakht
Contributor III

The Bootloader is compiled for RAM addresses and when debugging i can only see symbols and assembly code. i didn't use the BTL elf file since it's size (1.6 mb) is more than RAM (768 kb) and the binary file is only 200 Kb. So i think i will compile just the desired code to reduce RAM allocation for BTL .elf file. Any other suggestions ?

thanks a lot for your support

0 Kudos

6,375 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

elf file is not binary file which is loaded directly to RAM or flash. It contains also debugging information.

To be able to see the C code, you can use these two ways in trace32:

- when you load the code to flash, load the elf file:

pastedImage_0.png

Just example:

pastedImage_2.png

When elf file is load, you will see all the debugging information in the debugger now (assuming that the project is compiled appropriately and all the source files can be found at specified paths).

- if the code is already loaded in flash then you just need to load debugging information from the elf file (without flash programming). It can be done simply like this:

data.load.elf your_file.elf /NOCODE

Regards,

Lukas

0 Kudos

6,375 Views
chfakhtchfakht
Contributor III

Yes i know using elf file i can view source code but is there any difference between flash and RAM in debugging possibilities / limitations and also how about the performance of my code when writing it to flash or ram memory ? can you tell me How to load debugging information for RAM not for FLASH ? thanks Mr lucas

0 Kudos

6,375 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

the performance can be slightly different (application dependent). It depends on number of configured wait states on RAM and flash, it depends if the cache memory is enabled, it depends on configuration of flash features (prefetch buffers...).

The debugging information (elf file) is loaded still in the same way. It doesn't matter if the code is running from flash or from RAM. And I also can't see any limitations when debugging the code in RAM. The debugger doesn't care where the code is running from.

Lukas

6,375 Views
chfakhtchfakht
Contributor III

@Lukas Zadrapa yes you're right , the only limitation seems to be in the size flash / 6mb & RAM 768 kb only

6,375 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

I have just finished application note Serial Bootloader for MPC5748G and sent it for review. You can find preliminary version attached. It will be published in the near future.

How do you copy the code to RAM? Do you want just to load the code to RAM using debugger and then debug it? Do you have flash resident bootloader which will copy some code to RAM after start up and then it will be executed? Could you describe your procedure? Which IDE do you use?

Regards,

Lukas

6,372 Views
tony_huang
Contributor III

Hi,Lukas Zadrapa:

       Is there application project CAN Bootloader for MPC5643L? I think there are need two projects:one is bootloader project,another one is application project.  And also need  PC program.But I don't konw how to
do it. In the MPC55XX community,there is a Serial Bootloader for MPC5634 project,but is not CAN  Bootloader.

        

0 Kudos

6,372 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

we do not have CAN bootloader for MPC5643L. It is necessary to develop your own bootloader or buy it from SW vendors like Flash Bootloader 

I have also published application note for MPC5748G short time ago:

http://www.nxp.com/files/microcontrollers/doc/app_note/AN5319.pdf

http://www.nxp.com/files/microcontrollers/doc/app_note/AN5319SW.zip

I believe that this application note and the bootloader for MPC5634M on community provide enough clues to develop own bootloader.

Regards,

Lukas

6,377 Views
chfakhtchfakht
Contributor III

lukaszadrapa​  So here is the complete scenario:

1. Flash the application elf file using JTAG debugger from lauterbach (the application contains the BTL inside).

2. After that we use DMA to copy the BTL from FLASH memory to RAM at the desired adress.

3. The BTL will then erase the whole flash and then write to it a complete 6Mb file.

So when the BTL is running on RAM , i want to debug it ...

Indirectly related to the question: i have a problem while running BTL code and then it generate "bus error generated by CPU" when trying to flash the application again and also "Target processor in reset" for another board. Using halt core at power on reset didn't solve the second issue and for the first one the application continue to load into flash but when it reaches about 80% it give me the error ""bus error generated by CPU" "

i'm using trace32 and eclipse.

thanks

0 Kudos

6,376 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

does it mean that the bootloader can be used only one time? If so, why? You can flash the 6MB file directly... If some problem occurs during programming (communication error between bootloader and host or whatever else) then it's not possible to recover without JTAG device - you would have to program the bootloader again by JTAG...

Are you sure that the UTEST area is disabled for programming?

If you got message "bus error generated by CPU" then the image probably contains addresses out of flash. I guess it could be caused by wrong linker file. You can check the map file. Or the fastest way (from my point of view, at least) is to generate s-record file and check the addresses in the file. The s-record file is not generated by S32DS by default, so change the settings: Project -> Properties -> C/C++ Build -> Settings -> Cross Settings. Here enable "Create flash image". Then build the project and find *.srec file in Debug folder. Check the addresses if all of them fall to flash area.

Lukas

0 Kudos