• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 31 subscribers
  • Views 403 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LS0914: CAN Bootloader Updater

Alberto Persico
Prodigy 20 points
Part Number: TMS570LS0914
Other Parts Discussed in Thread: HALCOGEN

Hello,

I successfully implemented a CAN Bootloader for our design which uses a TMS570LS0914; i was wondering how can we manage to update the Bootloader itself by means of an application which write the Bootloader memory to the new one. 

Actually I just load the bin file in the C code as a "static const uint32_t newBootloader[] array ", and then I just run the following code.

uint8_t oReturnCheck  = 0;

uint32_t size_of_bootloader = sizeof(TMS570LS0914PGE_CAN_Bootloader_SW);
uint32_t index = 0;
while(index<size_of_bootloader)
{
oReturnCheck = Fapi_BlockProgram(index, (uint32_t)&TMS570LS0914PGE_CAN_Bootloader_SW[index], 8);/**/
index = index+8;
}

however, this does not seems to work

Application code start at 0x40020, App_status_Address is 0x40000.

Is a smarter way to do it ?

THanks

  • 0
    TI__Guru 69591 points

    Hi Alberto,

    We started working on your thread and will provide an update soon.

    --

    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    TI__Guru 69591 points

    Apologies for the delay and i am transferring this thread to an expert.

  • 0 in reply to jagadish gundavarapu
    TI__Guru**** 196176 points

    Hi Alberto,

    To update the bootloader, you need to erase the first flash sectors which are allocated for bootloader. The Application firmware downloads the bootloader, and copy the F021 Flash APIs related code to SRAM, and program the bootloader code to erased sectors using Flash API from SRAM.

    I am sorry we don't have example for bootloader itself update.

  • 0 in reply to QJ Wang
    Prodigy 20 points

    Hello QJ Wang,

    thanks for your answer. May I ask you, I am already using the TI Fee api to write data in the flash memory in the application firmware, will this work for wiring the bootloader sectors?

    I also was wondering, what are the sectors of the bootloader? Is it correct to say the memory should be erased starting from Address 0x0000  ? The app status address is at 0x40000, how can I know how many sectors I need to erase ?

    thanks! 

  • 0 in reply to Alberto Persico
    TI__Guru**** 196176 points

    Hi Alberto,

    Alberto Persico said:
    Is it correct to say the memory should be erased starting from Address 0x0000  ?

    It is correct. The bootloader is located in the first several sectors starting from 0x00000000.

    Alberto Persico said:
    how can I know how many sectors I need to erase ?

    Fapi_BlockErase(0x00000000, size of bootloader);

    When you download the bootloader, the driver will calculate the size. You can check the size in bootloader map file located in project debug folder.

  • 0 in reply to QJ Wang
    Prodigy 20 points

    Thanks QJ,

    I will try , so if in my application firmware the TI Fee was already configured in HALcogen I should not need to reconfigure the Flash 2021 api right? 

  • 0 in reply to Alberto Persico
    TI__Guru**** 196176 points

    1. You need to copy the Flash API to SRAM and execute them from SRAM because your Application firmware and bootloader are in the same flash bank. 

    2. Flash bank should be enabled. Bootloader and application are located in BANK0, but EEPROM is bank 7.

    3. Flash sectors should be enabled used by bootloader, please refer to the Fapi_Init(..) in our bootloader example

  • 0 in reply to QJ Wang
    Prodigy 20 points

    Hi QJ, 

    so, I am modifying the Bootloader firmware to use it as an application Firmware to update the bootloader; this should make it straightforward to update the bootloader form a specific application. so far I changed:

    APP_START_ADDRESS to match 0x00000

    APP_STATUS_ADDRESS to 0x30000 (in the bootloader is set to 0x40000 as I am using the Ti_Fee api in the bootloader so I had to move it further (it is actually working fine in the bootloader). 

    Is this correct? in this way if I am sending as address where to start the flash process 0x00, I am getting errors.

    I don't understand this condition that I found in the examples:

    1)Why if the flag "ENABLE_BL_UPDATE" is declared the condition is checking that the address is different from 0x00? I should flash the bootloader starting from 0.. Could you explain me if this is corrected or if it is a bug?

    2)Do i need to declare this flag in order to succed?

    3) Is it correct to use a different address for APP_STATUS_ADDRESS different form the one decalred in the bootloader in order to not mix both ?

    4)Do i need to modify the bl_link.cmd other than starting the program from addres 0x40020 ?

    Let me know thanks

  • 0 in reply to Alberto Persico
    TI__Guru**** 196176 points

    My bootloader example doesn't support the mechanism to update itself. Only changing the APP start address won't make the update work.

    The bootloader is located in flash, and execute from flash by default. To update itself means the bootloader has to call Flash APIs to erase the flash sectors used by itself. 

    To update itself, the whole bootloader has to be copied to SRAM and executed from SRAM. 

    Updating the bootloader from the bootloader itself or from the application is a risk. If the update fails, the MCU won't boot properly. 

  • 0 in reply to QJ Wang
    Prodigy 20 points

    Hi,

    don't get me wrong, my idea is not to update the bootloader from the bootloader itself.

    My idea, is to flash an application firmware containing the same code of the bootloader. When the actual bootloader jumps to the application after the flash is finished, the idea is that the application (which contains the same code of the bootloader ) will update the real bootloader from there. For this, the application will need to point the APP_START_ADDRESS to 0x00 so the flashing process will look at erasing and flashing the new bootloader starting from address 0.

    Just to say, some answer before you told me that the application need to load the flash api in SRAM in order to do that, and I think that by using the same code of the real bootloader should do the job right?

    If not, what do you suggest in order to update the bootloader? Are you saying that everytime I need to update it I need to acces to the programming through the JTAG? as this would be very difficult in a commercial procudct.

    regarding the other question, would you be able to clarify the answers? thanks so much

  • 0 in reply to Alberto Persico
    Prodigy 20 points

    Also, I understand that updating the bootloader from the application may be a risk, but thing is that in that cas you would need to use the JTAG. If  there is no way to update the bootloader, then I would need in any case to use the JTAG

  • 0 in reply to Alberto Persico
    TI__Guru**** 196176 points

    Bootloader is just a very small application designed to download application firmware in the embedded device. It should be developed bug-free. The bootloader is needed when you need to have the possibility to update your application firmware without having access to the JTAG header on the PCB. If you have to update the bootloader, you need to copy the bootloader to SRAM, download the new bootloader, then program to flash.