TM4C123GH6PGE: Bootloader corrupted. Not working properly after the device power down when flashing.

Selami Tastan

Prodigy 180 points

Part Number: TM4C123GH6PGE
Other Parts Discussed in Thread: UNIFLASH, EK-TM4C123GXL

Is there any solution run bootloader properly after power down device when loading program ?

How can i write a flag into flash memory when loading program done ?

How can i check this flag in StartApplication when bootloader starting ?

I read bl_startup_ccs.s file.

There is a prototype for the function (in the startup code) for calling the application.

void StartApplication(void);

Also, there is a UpdateHandler.

I did not figure out how that functions work.

over 4 years ago

0 Bob Crosby over 4 years ago

TI__Guru 72500 points

Would you please clarify if you are using the ROM based bootloader or a flash based bootloader?

0 Selami Tastan over 4 years ago in reply to Bob Crosby

Prodigy 180 points

It is rom based Bootloader. I did not know if there is a flash based bootloader.

Actually , i can write flag into memory. But i do not know how can i check when bootloader start up.

0 Bob Crosby over 4 years ago in reply to Bob Crosby

TI__Guru 72500 points

Here is a document from the latest version of TivaWare that describes the different bootloaders: SPMU301. In the description of the ROM based bootloader on page 9 you will see that there are three ways of running the ROM based bootloader. On reset, the CPU executes from ROM and checks location 0x00000004 for the value 0xFFFFFFFF (erased). This is the location of the reset vector. One method to minimize the impact of a power loss while programming is to split the object file into two files. One contains the data for bytes 0 - 0x7, and the other that contains the rest of the code, with the address starting at 0x1000. Program the rest of the code first, then program the first 8 bytes last. You need to use dynamic interrupt vectors, or before enabling interrupts have the vector table moved to your application code section (0x1000 or above). Now if you lose power while programming the application, upon restoring power you will still be in the bootloader. It is possible to lose power while programming the reset vector, but unlikely as the four bytes that make up the reset vector are programmed at the same time.

The second option is to use the BOOTCFG register and a GPIO pin to force the device into Bootloader mode. This is a good idea because you can recover from a power loss during programming, or if you accidentally program a bad code into the device.

0 Bob Crosby over 4 years ago in reply to Selami Tastan

TI__Guru 72500 points

Another option to consider is to use a flash based bootloader like the one in TivaWare: C:\ti\TivaWare_C_Series-2.2.0.295\boot_loader

In the configuration fjile bl_config.h, you can require the bootloader to check the CRC value of an application before leaving the bootloader. The details are described in the comments of bl_config.h which I have included below:

//*****************************************************************************
//
// Enables runtime and download CRC32 checking of the main firmware image.
// If this is defined, the boot loader will scan the main firmware image for
// an image information header (stored immediately above the vector table and
// marked by the words 0xFF01FF02 and 0xFF03FF04).  If the header is found and
// the CRC32 value it contains matches that calculated for the image, the
// firmware is run.  If the CRC32 does not match or the image information
// is not found, the boot loader retains control and waits for a new download.
// To aid debugging, if this option is used without ENFORCE_CRC being set, the
// image will also be booted if the header is present but the length field is
// set to 0xFFFFFFFF, typically indicating that the firmware file has not been
// run through the post-processing tool which inserts the length and CRC values.
//
// Note that firmware images intended for use with CRC checking must have been
// built with an 8 word image header appended to the top of the vector table
// and the binary must have been processed by a tool such as tools/binpack.exe
// to ensure that the required length (3rd word) and CRC32 (4th word) fields
// are populated in the header.
//
// Depends on: ENFORCE_CRC
// Exclusive of: None
// Requires: None
//
//*****************************************************************************
//#define CHECK_CRC

//*****************************************************************************
//
// This definition may be used alongside CHECK_CRC to remove the debug behavior
// which will allow an image with an uninitialized header to be run.  With
// ENFORCE_CRC defined firmware images will only be booted if they contain a
// valid image information header and if the embedded CRC32 in that header
// matches the calculated value.
//
// Depends on: None
// Exclusive of: None
// Requires: CHECK_CRC
//
//*****************************************************************************
//#define ENFORCE_CRC

0 Selami Tastan over 4 years ago in reply to Bob Crosby

Prodigy 180 points

Hi Bob,

Thank you for your valuable information.I noticed the source is flash based bootloader, not rom based. I could not distinguish at first.

Bob Crosby said:
Program the rest of the code first, then program the first 8 bytes last.

It is acceptable.

#define APP_START_ADDRESS 0x2800

I tried to program the rest of the code first , then program first page including 1024 bytes that is first page.

But not success after power down when loading program.

So , I did program at starting at APP_START_ADDRESS + 1024, last program APP_START_ADDRESS. Is it right ?

Also, i did not used CRC part. I think needs "binpack tool" which inserts the length and CRC values into the header.

There is a method CheckForceUpdate in bl_check.c.

I did program rest of the code, but not first page. First page Filled with 0xFF.

If i debug this method return 1 as expected, if the first page is filled 0xFF.

I think this part not working correctly when power down, or bootloader program area is damaged. How can it be ?

    //
    // See if the first location is 0xfffffffff or something that does not
    // look like a stack pointer, or if the second location is 0xffffffff or
    // something that does not look like a reset vector.
    //
    pui32App = (uint32_t *)APP_START_ADDRESS;
    if((pui32App[0] == 0xffffffff) ||
       ((pui32App[0] & 0xfff00000) != 0x20000000) ||
       (pui32App[1] == 0xffffffff) ||
       ((pui32App[1] & 0xfff00001) != 0x00000001))
    {
        return(1);
    }

There is uniflash memory browser image after power down device.

0 Bob Crosby over 4 years ago in reply to Selami Tastan

TI__Guru 72500 points

Using a CRC to validate the code before running is an optional feature only supported in a flash based bootloader.

I am not sure which interface you are using, but I checked this out using a UART serial bootloader and LM Flash Programmer. I first programmed the application code that was linked to start at address 0x1000. Then I programed the stack pointer and reset vector starting at address 0. It is important that the application not be in the first flash sector as the LM Flash Programmer will cause that sector to be erased before programming the reset vector.

0 Selami Tastan over 4 years ago in reply to Bob Crosby

Prodigy 180 points

I used several interface. Ethernet, Serial & CAN.

i think "program the rest of the code, then last first bytes " is not the only solution.

I think the problem is about reset vector .

I did not understand that,

Bob Crosby said:
I programed the stack pointer and reset vector starting at address 0.

I did start to program starting at APP_START_ADDRESS.

Could you write details ?

0 Bob Crosby over 4 years ago in reply to Selami Tastan

TI__Guru 72500 points

Ok, here is a detailed example. First, I have two projects in the attached .zip file. Use the Code Composer "File"->"Import" feature to import these two projects into your workspace. (I used Code Composer Studio version 10.1 and Code Generation Tools version 20.2.3 to generate these projects.

/cfs-file/__key/communityserver-discussions-components-files/908/blinky_5F00_0x1000.zip

Start with an EK-TM4C123GXL launchpad with erased flash. Use LM Flash Programmer to program the file blinky_0x1000.bin into the device. Start by configuring LMFlash Programmer to use the serial interface. You will need to determine which COM port is used by your EK-TM4C123GXL board. (You can use Windows Device Manager.)

Program the first file using an offset of 0x1000. Make sure the "Reset MCU After Program" is selected.

It should program 1482 bytes.

Now program the reset vector at location 0 as shown:

It should program only 8 bytes.

Now some background on the two projects. Blinky_0x1000 is the standard Blinky project example that comes with TivaWare but the link command file was modified. The definition of APP_BASE was changed from 0 to 0x1000. Also a line was added to force the start of the code to be at a known spot. This was done as a convenience because that start address is used in the other project.

    .startup: {startup_ccs.obj (.text:ResetISR)} > 0x1300

The project startVectors is a simple assembly language project that has the top of stack and start location hardcoded to addresses 0 and 4.

        .def Vectors
        .text
Vectors
        .word 0x20000200
        .word 0x00001301

0 Selami Tastan over 4 years ago in reply to Bob Crosby

Prodigy 180 points

I will work in the following day and give you feedback.

Thank you.

0 Selami Tastan over 4 years ago in reply to Selami Tastan

Prodigy 180 points

Hi again,

I was very busy, so I finished to work yet.

Before i said "i think "program the rest of the code, then last first bytes " is not the only solution.'

I was wrong. It is the right answer. i did test with Serial and CAN , it works as expected.

i think, i did configure project with wrong chip code before.

Thank you dear Bob.

Arm-based microcontrollers

Arm-based microcontrollers forum

TM4C123GH6PGE: Bootloader corrupted. Not working properly after the device power down when flashing.