TMS320F280049C: Using the Flash kernel flashapi_ex2_sci_kernel

Philip Webb

Part Number: TMS320F280049C
Other Parts Discussed in Thread: C2000WARE

I am trying to use the flashapi_ex2_sci_kernel to flash bank 0 via the sci interface.

I have built a simple application that runs from flash bank 0 and works when I download the code via XDS110 debug probe and the code successfully runs from flash when I power up the chip.

On configuring the boot pins so that the unit boots from SCI (boot 0 = 1 boot 1 = 0 ) I can successfully download the kernel via the SCI interface and gain autobaud lock with it. I can send down the first 22 bytes from my simple app and receive a checksum from the kernel which is correct.

However when I send down my first block it hits the following infinite while loop in flashapi_ex2_ldfu.c @ line 685

       #ifdef BANK0

            //
            // Check if the destination address is less than B1_RESERVED
            //
            if(BlockHeader.DestAddr < (uint32_t)B1_RESERVED)
            {
                //
                // Loop Forever. In the terminal of the Serial Flash Programmer,
                // new bytes will stop showing
                //
                while(1){};                                                                                           ///Line 685 *******
            }

        #endif

        //
        // For the BANK1 configuration, the destination address cannot be less
        // than B0_RESERVED. This is to prevent overwriting of the flash kernel
        //
        #ifdef BANK1

            //
            // Check if the destination address is less than B0_RESERVED
            //
            if(BlockHeader.DestAddr < (uint32_t)B0_RESERVED)
            {
                //
                // Loop Forever. In the terminal of the Serial Flash Programmer,
                // new bytes will stop showing
                //
                while(1){};                                                                                                ///Line 705 *******
            }

        #endif

My destination address (0x81628) is definitely less than B1_RESERVED (0x92008) as it is in bank 0. In fact all destination addresses will be less than this as 0x92008 is the top address of Bank 1 !!

If I change the kernel to be configured as Bank 1 I hit the second infinite while loop at line 705 because my destination address is less than B0_RESERVED (0x82008 ) because I am trying to program bank 0 which sits at 0x81000 to 0x82007 and my destination address is within this boundary.

I am some what confused by how I get this to work. Can anyone shed some light on how I build the flash kernel so that it will except my hex2000 file for code that runs from bank 0 ??

Kind regards

Phil Webb

over 5 years ago

0 Vamsi Gudivada over 5 years ago

TI__Guru* 87155 points

Phil,

Thank you for contacting TI on this.

I will work on this and get back to you in a day or two.

Thanks and regards,

Vamsi

0 Vamsi Gudivada over 5 years ago in reply to Vamsi Gudivada

TI__Guru* 87155 points

Phil,

I reviewed the code.

Bank0 build configuration is used to update Bank1 image. In this case, while updating the Bank1 image, the kernel does not erase or program the addresses less than 0x92008 (B1_RESERVED). This is to prevent erasure of the kernels that exist in Bank1's sector0 and sector1.

Bank1 build configuration is used to update Bank0 image. In this case, while updating the Bank0 image, the kernel does not erase or program the addresses less than 0x82008 (B0_RESERVED). This is to prevent erasure of the kernels that exist in Bank0's sector0 and sector1.

Let me know if you have any specific questions.

Thanks and regards,

Vamsi

0 Philip Webb over 5 years ago in reply to Vamsi Gudivada

Prodigy 140 points

Thank you Vamsi for the clarification.

I am , however still a little confused. The upgrade kernel that I build is built so that it runs in Bank1 and is capable of upgrading bank 0. Its destination address within the hex2000 generated file is 00091664. This corresponds with information in the generated map file shown below

ENTRY POINT SYMBOL: "_c_int00" address: 00091664

My application that I wish the kernel to receive and program into flash bank 0 has a destination address of 00080801. his corresponds with information in the generated map file shown below

ENTRY POINT SYMBOL: "_c_int00" address: 00080801

This destination address will be trapped by the upgrade kernel as it is less than 0x82008. Do I need to do something with my application build so that it shifts its entry point away from the reserved area of flash? If so how do I do that as my build is a standard TI project which runs from flash quite happily when downloaded via the XDS110 debug tool.

Why is there a few sectors reserved in the bank that my code is targeting? why can I not use all of it?

Cheers

Phil

0 Vamsi Gudivada over 5 years ago in reply to Philip Webb

TI__Guru* 87155 points

Phil,

Bank selection logic and the Flash kernels occupy the first two sectors and the application can occupy remaining sectors. We don't want application to overwrite the kernels and hence reserve the first two sectors.

Hence, in your application's linker command file, please do not map anything in the first two sectors.

As an example, please take a look at 28004x_flash_api_liveFirmwareUpdate_bank0_lnk.cmd available at C:\ti\c2000\C2000Ware_2_01_00_00\device_support\f28004x\common\cmd\28004x_flash_api_liveFirmwareUpdate_bank0_lnk.cmd.

You will notice that nothing is mapped to FLASH_BANK0_SEC0 and FLASH_BANK0_SEC1.

Thanks and regards,

Vamsi

0 Philip Webb over 5 years ago in reply to Vamsi Gudivada

Prodigy 140 points

Hi Vamsi

Thank you again for your answers and feedback it is much appreciated. I do , however, have a couple of questions about this.

You mention that the flash kernel and Bank selection logic occupy the first two sectors. However if I download to flash via the debug tool I can use all sectors of the flash for my code, how is that different to this method ?

What is the bank selection logic?

I currently download the Flash kernel to the other flash bank prior to downloading my App, therefore surely I have no flash kernel in the first two sectors of the Apps Bank. Or am I miss understanding something?

Also does this mean that this method of field upgrade reduces the available flash for your code by 2 sectors, therefore restricting the size of your code further?

I have modified my cmd file to push the start address down into the 3rd sector and this version is accepted by the flash kernel now , which is progress. However on booting to flash afterwards my code does not run. So not quite there yet :) I will be investigating this next.

However a better understanding of the reasons and side effects of this method of upgrade would be good.Is there other methods of field upgrade available that enable you to take advantage of all the sectors in the flash just like the 'debug download tools' offer ?

Thank you for your on going support

Phil

0 Philip Webb over 5 years ago in reply to Vamsi Gudivada

Prodigy 140 points

See question below.

0 Vamsi Gudivada over 5 years ago in reply to Philip Webb

TI__Guru* 87155 points

Philip,

What you are using now is LDFU (Live Device firmware upgrade).

This can be used to update Bank1 when your application is still executing from Bank0. OR

This can be used to update Bank0 when your application is still executing from Bank1.

Meaning, only one bank will be active at-a-time (from which application is executed) and the other one will be updated when a LDFU command is given. Once update is complete, a reset will be generated using watchdog. Upon reset, Bank selection logic (bankSelect) placed at the entry point 0x80000 in BANK0 gets executed. This logic branches to the most recently programmed bank. If no banks are programmed using LDFU, this logic will branch to the kernel setup so that a new image can be programmed in to the device. In the flashapi_ex2_ldfu.c, you might have noticed that Bank selection logic (bankselect) is assigned to codestart section (which gets mapped to Flash entry point 0x80000 in linker cmd). Device must be configured to boot to Flash at 0x80000 for this logic to get executed upon reset.

Summary: Bank selection logic is used to know the bank that has the latest valid application image.

When application is active from Bank0, if it receives a LDFU command from host, it will branch to Flash kernel available in the first two sectors of Bank0 to start streaming the Bank1 image and program it in Bank1. Similarly, there will be a Flash kernel in Bank1 that can stream the Bank0 image and program it in Bank0.

Debug Flash download tools load the Flash kernels in to RAM and they don't keep Flash kernel in Flash bank. Also, bank selection logic is not needed since Debug Flash download tools are not meant for LDFU. Hence, entire Flash bank can be programmed using the Debug Flash download tools.

Looks like you are not looking for LDFU. You are trying to update the firmware in both banks of F28004x using serial port when the application is not live. Correct?

If yes, then you can use the SCI Flash kernel (\C2000Ware_2_01_00_00\driverlib\f28004x\examples\flash\flashapi_ex2_sci_kernel.c) with CPU1_RAM build configuration. In this configuration, Flash kernels are linked for RAM space and do not occupy Flash space. This kernel is streamed in to the RAM from SCI boot loader from the host (\C2000Ware_2_01_00_00\utilities\flash_programmers\serial_flash_programmer\serial_flash_programmer).

Please go through http://www.ti.com/lit/an/sprabv4c/sprabv4c.pdf for more details.

If you have questions on serial flash kernels, please open a new post.

Thanks and regards,
Vamsi

0 Philip Webb over 5 years ago in reply to Vamsi Gudivada

Prodigy 140 points

Hi Vamsi,

Thanks for the explanation. I understand now and you are right that I do not need the Live bank up date.

Thank you for your clear explanation.

Kind regards

Phil

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F280049C: Using the Flash kernel flashapi_ex2_sci_kernel