WEBENCH® Tools/TDA4VM: Flashing of .xer5f with Lauterbach

Hello Rafal,

-0-

The .xer5f file is an ELF formatted object file. What included inside it will depend on which example in the PDK is built. TI provides toolchains which are bundled to compile objects to work with baremetal or rtos libraries for the R5. What address the elf sections are compiled for will depend on the linker file in use. The address range choices in the linker file will depend on the sw-platform memory map. The SOC includes many different cores that need memory to execute and the SW architecture dictates private and shared areas.

Certainly, Lauterbach's TRACE32 can burn an .xer5f object into many different memories. If the example xer5f is compiled to be an XIP image then that memory could be loaded using the TRACE32 FLASH interface (https://www2.lauterbach.com/pdf/norflash.pdf ). To execute the burned code your 'boot loader' would need to call it directly.  If the .xer5f image was compiled to run from DDR or some SRAM, then your bootloader would need to 'copy' it from the flash to the address its compiled for as seen in its ELF sections, then jump to that image. Burning into that flash part could use the same 'flash' APIs or it could use the 'FLASHFILE' APIs ( https://www2.lauterbach.com/pdf/serialflash.pdf  ).  Lauterbach provides an example in the ./t32/demo/arm64/hardware/j721e/*flash*.cmms and TI has some examples for writing at ./cmm-tda4_dra829/mcu-r5/burn_flash/*.cmm.  The FLASH/FLASHFILE APIs can take many input formats.  Often using binary is more convenient but you could use others if that is what your flow creates.

If you load your xer5f file into the TRACE32 simulator you can quickly look to see what address the elf image has been compiled for. Launch a ./t32/bin/<arch>/ t32marm executable using PBI=SIM in the config, then use "data.load.elf myfile.xer5f" to load the object.  Now use "sYmbol.Browse.sYmbol" to check out the image layout.  You could also just dump with compiler tools but its easier sort out using the debugger.

You should look through the PDK instructions for the memory map, look into your built example, and look into the example CMMs and TRACE32 PDFs.  With that information, the process should become clearer.

memory map:

http://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/psdk_rtos_auto/docs/user_guide/developer_notes_memory_map.html

r5 toolchain docs/elf format:

http://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/ti-cgt-arm_20.2.0.LTS/README.html

-1-

The system boot for the SOC happens via mask ROM code and TI-Firmware.  The TI firmware will look for a signature in whatever the boot device is.  The loader knows how to look for a named file in a FAT filesystem, or for a raw signature in the device.  The rom+firmware loads that booter and hands over execution to it.  That boot code is now what would use your burned xer5f image.  Maybe it just reads it, maybe it jumps to it if XIP, maybe it loads it to DDR and jumps to it.

Regards,

Richard W.