LP-AM263P: CCS Debugger treatment of Load and Run adresses

Rens Bossers said:

So it seems to me like CCS debugger uses section load adresses as the adress where a section needs to be run. Which would seem counterintuitive, as this essentially makes the 'load adress' option for all sections useless - as CCS debugger doesn't work.

Is this assumption correct? Is there a reason for CCS debugger not using the RAM/run adress for debug purposes? Is there anyway to make CCS debugger use run adresses instead of load adresses for debug?

The CCS debugger will use whatever run address is in the debug symbols. So assuming the executable is compiled correctly with the correct load/run addresses and the applicable code is copied from the load and run address, then the debugger should be able to properly debug the code executing from the run address.

Rens Bossers said:

Running CCS debugger:

The error in the screenshot below is a flashing failure. The flash algorithm failed to execute. I get this also when I change the load memory to flash (even if the run address is also set to the same). I'll bring this thread to the attention of the device experts for further comment.

As mentioned in AM263Px MCU+ SDK: Enabling XIP or eXecute In Place, the application entry point, interrupt vectors and initial code upto main() should still execute from RAM. After main() the code can execute from flash. I see that you're trying to place R5F_VECS into flash instead of RAM. Only the .text and .rodata needs to be stored into flash.

Thanks for your comments. Perhaps I did not make the example very clear. I only used R5F_VECS section as an example of the CCS debugger behaviour changing when load adress changes, I'm aware xip has other requirements.

As we want to control section placement in the generated mcelf and subsequently in flash, ideally the load adress for each section would be flash based (0x6xxx) as then I can use the physical adress to order segments before they're written into the mcelf. Each section of course still has its RAM-based run adress (0x7xxx).

However, as I understand it, the issue with this approach is that CCS debugger also utilises the load adress for each section for debugging sessions, not the run adress - as for a normal debug session we want to load the program to RAM. If I set a flash-based adress for the load adress, CCS debugger will not be able to load to this as it's not a location in ram. Does this sound correct?

I was hoping there might be a workaround for CCS debugger where we can force the debugger to always utilise the run adress for each section to load section data to instead of the load adress. This would mean you could specify different load/run adresses and the debugger would still work. This is probably wishful thinking.. from the sound of it this is not possible?

Rens Bossers said:

However, as I understand it, the issue with this approach is that CCS debugger also utilises the load adress for each section for debugging sessions, not the run adress - as for a normal debug session we want to load the program to RAM. If I set a flash-based adress for the load adress, CCS debugger will not be able to load to this as it's not a location in ram. Does this sound correct?

No, this should not be the case assuming that the correct information regarding the load and run addresses are in the debug symbols for the executable. The CCS debugger should parse the debug symbols and use the load address there for the address to load to and use the run address in the symbols for debugging. 

Rens Bossers said:

This would mean you could specify different load/run adresses and the debugger would still work. This is probably wishful thinking.. from the sound of it this is not possible?

This should already work - again assuming the above mentioned conditions.

Ok thank you for the clarification - much appreciated!

In that case, as you say the current issue I've got then is finding reason for the flasher not working.

Follow up questions:

1: Are there any limitations on section format for CCS debugger? Things which come to mind are a) maximum section size or b) alignment - do all sections need to be page-aligned to the flash device (in this case 256 bytes)

2: Presumably the following executables (depending on board type) handle loading sections into either flash/ram memory. Is there more information available on the source of these? Would be very useful to know the setup differences between e.g. am263px_cc_flasher.out, am263px_lp_flasher.out and am263px_sip_flasher.out. Afaik, flash driver setup should be very similar across cc and lp

3: From where in the process is the am263px_cc_flasher.out called? Looking through all the .gel files, it appears we pass through most of the init steps in the general AM263Px.gel setup, but I'm struggling to find a gel function which calls this loader. Or is this defined elsewhere?

Thanks for your patience on this one..

These are questions I will defer to the device experts on.

Just to ask for an update - have the device experts come to any conclusions? Thanks

Apologies for the delay.

Rens Bossers said:

2: Presumably the following executables (depending on board type) handle loading sections into either flash/ram memory. Is there more information available on the source of these? Would be very useful to know the setup differences between e.g. am263px_cc_flasher.out, am263px_lp_flasher.out and am263px_sip_flasher.out. Afaik, flash driver setup should be very similar across cc and lp

You're right, this is the flash writer application. The source can be found at {SDK_PATH}/tools/flasher/jtag_uniflash. The source code is same for all the boards, the difference is the flash reset mechanism that is captured in board.c file of the project. In case of SIP board, even the flash configuration varies which is modified via syscfg. 

Rens Bossers said:

3: From where in the process is the am263px_cc_flasher.out called? Looking through all the .gel files, it appears we pass through most of the init steps in the general AM263Px.gel setup, but I'm struggling to find a gel function which calls this loader. Or is this defined elsewhere?

The executable is called from a prebuilt library "FlashSitaraMCU.dll" in Windows and "libFlashSitaraMCU.so" in Linux. 

Rens Bossers said:

1: Are there any limitations on section format for CCS debugger? Things which come to mind are a) maximum section size or b) alignment - do all sections need to be page-aligned to the flash device (in this case 256 bytes)

I am not sure if there is a maximum section size limit, but yes the sections need to be page aligned. Let me check about the maximum size and get back to you.

Best Regards,
Aswathi

Thanks for the confirmation Aswathi. In that case, page alignment is probably contributing to the issue at the moment.

When you change load address to be flash-based for any (page-aligned) section, are you able to get flashing through CCS debugger working?