• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 420 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/MSP432E401Y: Writing 0x00:0x07 with ROM bootstrap loader (BSL)

Anthony Kremor
Prodigy 135 points
Part Number: MSP432E401Y

Tool/software: TI-RTOS

Hi,

We are using the ROM bootloader to add a firmware upgrade capability to our device. Our application is built around TI-RTOS and does not include the bootloader itself in flash (because we are using the one in ROM). The bootloader is triggered by configuring BOOTCFG with a GPIO trigger pin and then asserting this pin followed by a reset of the core (toggle nRST externally). We have been able to successfully enter the ROM bootloader and have achieved connectivity (seeing ACK's and appropriate responses to the Get Status messages).

Our problem is that when downloading our application using the bootloader it appears to write all bytes correctly *except for the first 8* (those in the vector table). Our TI-RTOS application is built/linked starting from 0x0000.0000 so we send a download configuration message with our program length, and a program start address of 0x0000.0000.

Is it possible to use the ROM bootloader to write the entire application starting at 0x0000.0000? If not, what approach should be taken to allow us to flash a TI-RTOS application? We note the BSL users guide (

http://www.ti.com/lit/ug/slau746a/slau746a.pdf

) does state that performing a download to address 0x0000.0000 triggers a bootloader update. Is this true when using the ROM bootloader (not a flash based one)?

Desired application image at 0x00-0x14 (for example):

20016360 0005434D 0000DDF5 0004DC3D 0004A189 0005AE75

Actual image seen when connecting the debugger to the chip and inspecting its memory.

FFFFFFFF FFFFFFFF 0000DDF5 0004DC3D 0004A189 0005AE75


Thank you,
Anthony

  • 0
    TI__Mastermind 22580 points
    Hello Anthony,

    You should be able to program the whole application starting from location 0 using ROM Bootloader. I have done this in the past, but I did not use TI-RTOS based project.

    Can you check if programming a non-RTOS based binary, like "blinky", exhibits the same behavior?

    Also what tool are you using to upgrade the firmware? What peripheral are you using to send firmware?

    Did you already refer the following SimpleLink Academy Lab on Bootloader for MSP432E4 MCUs? dev.ti.com/.../

    Thanks,
    Sai
  • 0 in reply to Sai Reddy
    Prodigy 135 points
    Hello Sai, thank you for your response.

    It is good to know what we are attempting to do is technically possible. It sounds like there might be an implementation error on my side.

    I will attempt to program a non-RTOS project. We are using another MSP432E401Y as the 'firmware upgrade master', connected to the UART0 port on the firmware upgrade target. We have implemented the protocol as described in SLAU746A, not using a BSL rocket or the computer based implementation.

    We have successfully done the linked lab, however this was with the computer based programmer which is not suitable for our application (the firmware update needs to come from the other MSP432E).

    I have packet captures of the UART lines between the two chips; is there anything I should be foccusing on to determine what is going wrong? For example, is the download command likely where the issue is occuring (given it is the one that specifies where to start loading bytes)?

    Thanks,
    Anthony
  • 0 in reply to Anthony Kremor
    Prodigy 135 points
    Hi Sai,

    I have attempted to upload a non-RTOS binary as requested (the blinky example project) and have found that this does work. The programmed firmware works after a reset and does show valid values located at 0x00.

    In the process I have restructured some aspects of the code. I have then tested with the TI-RTOS binary again and found that this also works. I suspect there was an issue with the programmed size versus the actual size of the binary being sent.

    Thank you very much for your help, especially around confirming that an update at 0x0000.0000 is possible.

    Thanks,
    Anthony

**Attention** This is a public forum