I am working to add two 16-bit CRC values to our codebase at compile time in order to verify the integrity of the program text/data stored in flash memory and the text/data stored in QSPI. I have managed to implement this functionality using srecord and the solution suggested in this NXP Community post.
The problem is that this procedure does not integrate tightly with our standard build-compile-debug process in MCUXpresso. I have been able to integrate the process with MCUXpresso by adding the Post-build steps shown below. The three steps are to 1) copy the .axf file to a .srec file, 2) perform the CRC calculation and insertion at the proper addresses, and 3) Copy the .srec file back to a .axf file.
arm-none-eabi-objcopy -v -O srec "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.srec"
../program_crc/srecord-1.65.0-win64/bin/srec_cat.exe @../program_crc/srec_command.txt
arm-none-eabi-objcopy -v -I srec -O elf32-littlearm "${BuildArtifactFileBaseName}.crc.srec" "${BuildArtifactFileName}"
This works well in the sense that the build process is now entirely integrated with MCUXpresso. However, the conversion from AXF to SREC and back again removes all of the debug information so that debugging is no longer possible.
Has anyone been able to calculate and insert a CRC at compile time without losing all of the debug information stored in the AXF file? There is a suggestion here which modifies the linker script. However, MCUXpresso now uses managed linker scripts which I would like to maintain. Is it possible to do this with templates?
Thanks for any suggestions!
FYI: we are using MCUXpresso v11.7.0 and developing for an MK82FN256 microcontroller.
Solved! Go to Solution.
Hi @med_engineer ,
as for the linker script: did you know that you can use Freemarker to extend/modify it? I'm using it for example to build bootloaders, see https://mcuoneclipse.com/2019/10/06/linking-bootloader-applications-with-eclipse-and-freemarker-scri...
And you don't 'loose the debug information':
a) create a binary file from the .axf with the CRC inserted using SRecord
b) flash the binary file
c) debug with the symbols of the .axf (which has all the debug information)
You can tell the debugger not to flash, but to use the .axf for debug information, for example see
https://mcuoneclipse.com/2020/11/03/debugging-bootloader-and-application-with-one-debug-session/
I hope this helps.
@ErichStyger Thank you for the suggestion! Your second suggestion to pull the symbols from the AXF file and the application code from the SREC file solved my issue. Debugging is now completely seamless and works as one would expect.
Just to be clear for anyone else who sees this topic in the future; The steps below are what I had to do in MCUXpresso in order to implement this solution.
Hi @med_engineer ,
as for the linker script: did you know that you can use Freemarker to extend/modify it? I'm using it for example to build bootloaders, see https://mcuoneclipse.com/2019/10/06/linking-bootloader-applications-with-eclipse-and-freemarker-scri...
And you don't 'loose the debug information':
a) create a binary file from the .axf with the CRC inserted using SRecord
b) flash the binary file
c) debug with the symbols of the .axf (which has all the debug information)
You can tell the debugger not to flash, but to use the .axf for debug information, for example see
https://mcuoneclipse.com/2020/11/03/debugging-bootloader-and-application-with-one-debug-session/
I hope this helps.