OpenBLT Bootloader

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Infineon TriCore AURIX TC3 ======

===== Remap user program base address =====

When using the OpenBLT bootloader, both the bootloader and the user program (your firmware) resides in the same flash memory. Furthermore, the bootloader needs to always run first after each microcontroller reset event. As such, the first part of flash memory is reserved for the bootloader. This is the part where the CPU expects the vector table with the reset handler. Consequently, the base address of where the user program is located in flash, needs to be moved forward to make room for the bootloader.

To determine and control how much space the bootloader reserves for itself, take a closer look at the flash driver. Specifically the flashLayout[] array. You'll notice that the first few entries in this table are commented out. The commented out entries defined the space reserved for the bootloader. Refer to the following example:

{{:manual:ports:tricore_tc3_flashlayout_reservation.png?|}}

This flashLayout[] array reserves the first 32kb (0x8000) bytes of flash for the bootloader. In this case, you need to move the base address of your user program forward by 32kb. With other words, you need to edit your firmware's linker script to change the base address of non-cached flash from 0xA0000000 to 0xA0008000 and of cached flash from 0x80000000 to 0x80008000

Refer to the demo user program for an example on how you can achieve this. There a macro named OPENBLT_RESERVED_SIZE was added to the linker script. With the help of this macro, everything that is normally located at the start of program flash 0 is moved forward by 32kb. Brief overview of the affected linker script sections:

{{:manual:ports:tricore_tc3_move_base_linkerscript.png|}}

===== 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:

1) 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|}}

2) 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

Page Tools
