User Tools

Site Tools


manual:ports:tricore_tc3

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
manual:ports:tricore_tc3 [2022/11/07 12:00]
voorburg [Checksum location]
manual:ports:tricore_tc3 [2023/09/18 11:29] (current)
voorburg [Post-process the Motorola S-record]
Line 36: Line 36:
  
 {{:​manual:​ports:​tricore_tc3_cs_linker_changes.png|}} {{:​manual:​ports:​tricore_tc3_cs_linker_changes.png|}}
 +
 +===== Generate the Motorola S-record =====
 +
 +OpenBLT'​s PC tools for performing a firmware update on your microcontroller,​ assume that the firmware file of your user program is in the Motorola S-record format. All software development IDEs support a feature for generating a firmware file in the Motorola S-record format. You just need to enable this feature. ​
 +
 +In the case of the AURIX Development Studio, you can add the following to the linker'​s command line pattern:
 +<​code>​
 +-Wl${OUTPUT_FLAG}"​${BuildArtifactFileBaseName}.srec:​SREC"​
 +</​code>​
 +
 +{{:​manual:​ports:​tricore_tc3_generate_srecord.png|}}
 +
 +===== Post-process the Motorola S-record =====
 +
 +The generated S-record in not yet suitable for performing a firmware update with the OpenBLT bootloader. Two issues need to be fixed during a post-processing step:
 +
 +  - The S-record contains program code and data that is scattered over both the cached and non-cached regions of program flash. The bootloader expects all program code and data to be in just the non-cached regions.
 +  - The S-record includes the "boot mode header"​(BMHD) tables for the user configuration bock region in flash. The bootloader itself already includees the BMHD tables such that the bootloader always runs first, after a poweron or software reset event. Therefore the data for the UCB region needs to be removed.
 +
 +The demo user program includes a batch-file that automatically corrects these issues. It is called "​postbuild.bat"​ and is located in the "​Cmd"​ sub-directory. You can reuse this batch-file for your own firmware. You just need to configure your software development IDE such that it calls this batch-file.
 +
 +Eclipse CDT based IDEs include a configuration option, where you can configure a command to run as a post-build step. This is the ideal location to call the batch-file:
 +
 +{{:​manual:​ports:​tricore_tc3_postbuild_step.png|}}
 +
 +This approach works for version 1.9.8 and newer of the AURIX Development Studio. Older versions (e.g. 1.7.2) of the AURIX Development Studio have a problem with the post-build steps. Whatever command you enter will result in a build error.
 +
 +Luckily, there is a simple workaround for this. At the end of a build, the AURIX Development Studio calls the tool "​elfsize"​ to print size information about the firmware'​s ROM and RAM usage. You can hijack its command to additionally call the "​postbuild.bat"​ batch-file. Simply change the Print Size command line pattern from:
 +<​code>​
 +${COMMAND} ${INPUTS} ${FLAGS}
 +</​code>​
 +
 +to:
 +
 +<​code>​
 +${COMMAND} ${INPUTS} ${FLAGS} && ${ProjDirPath}/​Cmd/​postbuild.bat "​${BuildArtifactFileBaseName}.srec"​
 +</​code>​
 +
 +{{:​manual:​ports:​tricore_tc3_postbuild_hack.png|}}
 +
 +When the calling of the "​postbuild.bat"​ batch-file is properly configured, you can see the following output in the Console-window at the end of the build:
 +
 +{{:​manual:​ports:​tricore_tc3_postbuild_console.png|}}
 +
 +
 +
  
manual/ports/tricore_tc3.1667818853.txt.gz ยท Last modified: 2022/11/07 12:00 by voorburg