• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 159 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.

MSPM0G3519: secondary bsl uart code debugging problem

Dibyarekha Maharana
Prodigy 100 points

Part Number: MSPM0G3519
Other Parts Discussed in Thread: UNIFLASH

Hi,

I am using MSPM0G3519 Launchpad. I am working on upgrading firmware over bluetooth. 

First I tried with the code bsl_software_invoke_app_demo_uart, which uses ROM BSL, I sent the firmware code I want to upgrade using docklight , and the firmware is upgrading successfully, but here I am facing following problems.

  1. I need to send the bsl packets on uart0 only, can I change it to any other uart?
  2. while sending the bsl packets If there is any power failure then I have nothing in the board as i am doing mass erase before sending program data command. how to overcome this?
  3. I want to use secondary bsl. can I?
  4. I gone throgh the secondary_bsl_uart code. but I am not able to understand how to test it?
  5. while debugging this code using ccs, I am getting following errorFlash Programmer: Invalid mass erase command
    File Loader: Memory write failed: Flash Programmer: Error, Attempting NONMAIN write without erasing!
    GEL: File: C:\Users\dibyarekha\workspace_ccstheia\secondary_bsl_uart\Debug\secondary_bsl_uart.out: Load failed. 

how to solve it?

Its Very Urgent. Please suggest.

 

 

  • 0
    TI__Mastermind 31025 points

    Hi Mahar,

    Please refer to below documents for the customized BSL (secondary BSL) implementation:

    MSPM0 Bootloader User's Guide 

    MSPM0 NONMAIN Flash Memory Configuration Guide

    MSPM0 Bootloader Implementation Guide 

    Few of other comments below:

    Dibyarekha Maharana said:
    while sending the bsl packets If there is any power failure then I have nothing in the board as i am doing mass erase before sending program data command. how to overcome this?

    Program the 0x0 address at last, and if any power failure happens before the final write, then an empty (0xFF) of address 0x0 will force the MCU enter the BSL mode directly.

    Dibyarekha Maharana said:
    while debugging this code using ccs, I am getting following errorFlash Programmer: Invalid mass erase command

    The CCS example you used have NVM modification, so users should set the flash erase property to include the NONMAIN memory.

    Important Note: make sure the NONMAIN has been programmed with correct data if erased, otherwise, the device might be permenantly locked.

    B.R.

    Sal

  • 0 in reply to Sal Ye
    Prodigy 100 points

    Hi Sal,

    I tried the first step related to ROM BSL. It is working fine. But still one problem is there, after entering into the ROM BSL Mode , when I am sending the connection packet to bsl, BSL is not responding. It seems it's taking some time. How much time it needs to accept the packet and respond to it?

    Now BSL is accepting packets on UART0. Can it change to any other UART?

    As per the solution provided by you, my flash got erased and if any problem is there then, If I am programming the 0x00 memory location at last then it should stay on bsl mode expecting again for the new firmware code. Is there any other way, where if any problem occurs then at power on , it should run the 1st firmware only. Means first firmware should not get erased.

    Regarding Secondary BSL, I have already gone through the pdf's you have shared. I read the scetion6.1.1 in the MSPM0 Bootloader's Guide, but i am not able to test this code. How can I test this code? Can you give me steps to test this code? Do I need to make any code changes?

    I have tried erasing main and nonmain memory necessary sectors only, still it didnot solve my problem.

    As my goal is to upgrade firmware, which method will best suit to me. I want firmware should upgrade properly, During firmware upgrade, if any problem rises, then board should not dead, it should run with the old firmware.

    Now I am using the method of sending bsl packets using docklight. I am converting the .bin file to hex and preparing bsl packets each with 16 bytes hex. Is this the correct way? Can I take more than 16 bytes of data in 1 bsl packet for program data. Instead of converting the .bin to .hex can't I directly use the hex file. Once I tried using .hex file in uniflash, it was not working. What is the problem with the .hex file?

    Please help me in clearing my doubts.

  • 0 in reply to Dibyarekha Maharana
    TI__Mastermind 31025 points

    Hi Mahar,

    Dibyarekha Maharana said:
    I tried the first step related to ROM BSL. It is working fine. But still one problem is there, after entering into the ROM BSL Mode , when I am sending the connection packet to bsl, BSL is not responding. It seems it's taking some time. How much time it needs to accept the packet and respond to it?

    I have no experiment record on this, but this is expected to be small. maybe ms level.

    Dibyarekha Maharana said:
    Now BSL is accepting packets on UART0. Can it change to any other UART?

    No, ROM BSL can only use UART0.This is mentioned in the NONMAIN UG and  BSL UG.

    Dibyarekha Maharana said:
    As per the solution provided by you, my flash got erased and if any problem is there then, If I am programming the 0x00 memory location at last then it should stay on bsl mode expecting again for the new firmware code. Is there any other way, where if any problem occurs then at power on , it should run the 1st firmware only. Means first firmware should not get erased.

    Firmware is stored in flash. flash should be erased firstly and then program.

    The doable way is that users maintain a bootloader at 0x0, and have two flash range to store the image1 and image2. In the bootloader which is kept unerased, it should decide which image should be executed.

    Dibyarekha Maharana said:
    Regarding Secondary BSL, I have already gone through the pdf's you have shared. I read the scetion6.1.1 in the MSPM0 Bootloader's Guide, but i am not able to test this code. How can I test this code? Can you give me steps to test this code? Do I need to make any code changes?

    You can refer to chapter 5.3 of MSPM0 Bootloader Implementation Guide, I think there is no other modification required to test the example.

    Dibyarekha Maharana said:
    I have tried erasing main and nonmain memory necessary sectors only, still it didnot solve my problem.

    I tried in my side, it works. Maybe you can share some figures of the settings / errors for my reference.

    I assume you flash/debug the project with CCS.

    Dibyarekha Maharana said:
    Now I am using the method of sending bsl packets using docklight. I am converting the .bin file to hex and preparing bsl packets each with 16 bytes hex. Is this the correct way? Can I take more than 16 bytes of data in 1 bsl packet for program data.

    Yes, the only requirements is 8-byte aligned and maximum buffer size, see chapter 4.3.4 of MSPM0 Bootloader User's Guide.

    Dibyarekha Maharana said:
    Once I tried using .hex file in uniflash, it was not working

    I suggest you tried to program by SWD firstly with prepared hex file, in case you hex file is not correct with format.

    We need set the hex file with 8-byte aligned during project build.

    B.R.

    Sal