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
Last revision Both sides next revision
manual:ports:tricore_tc3 [2022/11/07 12:02]
voorburg
manual:ports:tricore_tc3 [2023/09/18 11:29]
voorburg [Post-process the Motorola S-record]
Line 37: Line 37:
 {{:​manual:​ports:​tricore_tc3_cs_linker_changes.png|}} {{:​manual:​ports:​tricore_tc3_cs_linker_changes.png|}}
  
-===== Post-process the S-record =====+===== 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 work 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.txt · Last modified: 2023/09/18 11:29 by voorburg