• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 311 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.

Original question:

LP-MSPM0G3507: failed to upload the secondary bootloader, non-main contents error

MSPM0G1507: Bootloader is causing SWD debugger to not work

Jing Yuan Tan
Prodigy 70 points
Part Number: MSPM0G1507
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Hi, I'm using secondary bootloader like so. I've configured the .cmd file correctly, and somehow able to flash another firmware one time (to 0x0000) using a modified BSL GUI (we are using half-duplex uart). (This procedure is extremely flaky too, but let's talk about it in a separate thread).

Anyway, the GUI reports a success, but the application I've flashed in doesn't run. Subsequent attempts to run the bootloader do not work too. And the GUI's success seems real too, as I've tried interrupting the firmware update by removing power and the GUI reports a failure.

Most problematic is that when I use either Theia v20.0.1.4 or Uniflash v9.0.0.5086 to view the flash memory, I keep getting this error:

At this point, it is impossible to do anything with the XDS110 debugger (run debug, flash new firmware), except to factory reset the target and try again. Luckily, that works! But it also means I have no way of debugging what's really going on.

On a related note: this seems to be related to BSL entry. After I have done factory reset, if I flash in a "normal" application with this line of code:

DL_SYSCTL_resetDevice(DL_SYSCTL_RESET_BOOTLOADER_ENTRY);

It will cause the PRSC failure to happen as well, requiring a full factory reset to recover the situation. This happens when the Secondary BSL is loaded in the address 0x6000, but also when no Secondary BSL is loaded.

Is this expected behaviour that using the BSL causes SWD debugger to stop working forever? Is there any way to figure out why I'm unable to run my target application? 

  • +1
    TI__Genius 16000 points

    Hi Jing,

    There are a couple of notes here:

    The first and simplest one - we do have an errata released relating to BSL software invoke as you've shown in your pasted code above - please see the errata sheet item BSL_ERR_01. Basically you need to take certain considerations just before invoking BSL via software.

    To the other items - I am curious what items you have changed in the secondary bootloader example to get to this point? There are quite a few things that can happening when defining a custom bootloader that would result in the device being stuck and requiring a factory reset.

    If your device is getting stuck and requiring a factory reset every time you run your bootloader, my assumption is that you are hitting an NMI or hard fault inside of your bootloader. This is most likely caused by the device accessing invalid memory. 

    Have you also tried using the BSL host feature in Uniflash with the verbose output to see what the device is returning to the BSL host? This could reveal potential issues. The fact that the GUI indicates that the BSL has successfully loaded a program, then the device doesn't execute the application makes me think that it is not jumping to the correct application code. This issue would begin with the reset vector that you've provided the device.

  • 0 in reply to Dylan OBrien
    Prodigy 70 points

    Hi Dylan, thank you for your support!

    As suggested by the errata you mentioned, I used the invokeBSLAsm(); function from the "bsl_software_invoke" example to jump to the BSL. All problems are solved now!

    I've added an incomplete code snippet for future forum users' reference: