Differences

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

--- manual:ports:tricore_tc3 [2022/11/07 10:03]
voorburg created
+++ manual:ports:tricore_tc3 [2023/09/18 11:29] (current)
voorburg [Post-process the Motorola S-record]
@@ Line 16: / Line 16: @@
 ===== Checksum location =====
+A 32-bit signature checksum value is programmed by the bootloader at the end of a programming session. After each power-on or reset event, the bootloader verifies the correctness of this checksum to determine if a user program is present and can be started.
+On the TriCore AURIX TC3, the signature checksum is calculated over the first 28 bytes (0x1C) of the user program. The bootloader stores the 32-bit checksum value from 0x1C-0x1F after the base address of the user program in flash.
+For a TriCore AURIX TC3 firmware, the first 32 bytes (0x20) of the user program are meant for placing the function _START(), which is the reset handler. This function doesn't actually require the full 32 bytes of space reserved for it. Therefore this 32 byte region can be shrunk to 28 bytes, opening up 4 bytes for the 32-bit signature checksum value.
+With other words, for this signature checksum mechanism to work properly, the user program must shrink the 32 byte region that is reserved for function _START(), to 28 bytes. Next, place a dummy value for the signature checksum at the 4 bytes that just became available.
+Theoretically, you don't have to make any changes to make this work. This is because the linker script already reserves 32 bytes for function START(). This is 0x00-0x1F after the base address of the user program in flash. However, this function is actually smaller than this. Consequently, no harm is done when the bootloader stores the calculated 32-bit checksum value, by overwriting the flash at 0x1C-0x1F after the base address of the user program in flash.
+For correctness, the following optional steps explain how you could properly shrink the section reserved for function _START() and reserve space for the bootloader to write the 32-bit checksum value:
+) Add a constant 32-bit dummy value for the signature checksum to one of your source files, together with a compiler specific #pragma to define a new section. This section name can later on be used in the linker script to make sure it is placed at 0x1C-0x1F after the base address of the user program in flash. Example for the Tasking compiler:
+{{:manual:ports:tricore_tc3_cs_constant.png|}}
+) Shrink the 32 bytes, reserved for function START(), to 28 bytes. Furthermore add a section for the 4 bytes that now became available, such that the linker stores the constant 32-bit dummy value there. Example for the Tasking compiler:
+{{: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|}}

OpenBLT Bootloader

User Tools

Site Tools

Differences

Page Tools