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

MSPM0G3507: What happens if BSL_invoke pin is active after device reset after programming?

Marco Marder
Prodigy 100 points
Part Number: MSPM0G3507
Other Parts Discussed in Thread: SEGGER,

Hello,

we have the situation that the BSL_invoke pin can be high if the device is reset by the programmer/debugger after flashing the binary.

It is a PoC design so the hardware is not 100% correct nevertheless we wonder about the behavior in such cases.

  • When the device is programmed with a debugger and then reset by the debugger to start and the BSL_invoke pin is active then, according BSL guide, the device should enter bootloader and checking for activity on I2C and UART interfaces. If there is none then the device goes to standy.  If there is some activity detected yet the arriving packets are invalid the bootloader will put the device in sleep mode. What are the recovery actions from this standby and sleep modes? 

We observe that when programming with debugger (SEGGER Ozone) the debugger sometimes suddenly "fails / report error" after triggering a reset after programming. We believe this happens because BSL_invoke pin is high and bootloader is entered.

This state then persists and we fail to connect with the debugger. Also pulling BSL_invoke pin low (inactive) and re-trying does not help.

While we still can program with e.g. SEGGER JFlash we can't debug anymore. This happened to multiple boards already.

Any clues/hints what is going on here?

Version Set:

  • MSPM0 G3507S TIX368B AL07 G4 (probably some early production samples?)
  • Housing: VQFN32
  • MSPM0 SDK 1.20.1.6
  • SEGGER JLink  V792 (same with latest version)
  • SEGGER Ozone V330b (same with latest version)

Regards Marco

  • 0
    TI__Mastermind 39755 points

    What do you mean with "While we still can program with e.g. SEGGER JFlash we can't debug anymore. "? If you try to debug what happens?

    Can you disable the BSL function in SYSCTL?

  • 0 in reply to Eason Zhou
    Prodigy 100 points

    We can still program the binary to the MCU with JFlah and Ozone. Yet  in the Ozone Debugger when the program is started and the debugger is supposed to halt the MCU at main (after the programming step) the debugger reports an error - unfortunately I can't reproduce it as the hardware is completely locked now .. I can't even connect to target with debugger anymore.

    We are not using CCS IDE but VS Code and CMake. So I can't deselect "Enable BSL" in SYSCTL .. can you tell me what settings are changed in the driver lib by SYSCTL if I deselect the Enable BSL option? Then I can apply these in out setup .. but it is probably complicated right because the boot config area in flash is specially protected ...

  • 0 in reply to Eason Zhou
    Prodigy 100 points

    I created a setup where I can use our hardware with a TI debugger and CCS .. I selected the empty_driverlib example for LP_MSPM0G3507 and just unchecked the "Enable BSL" option. Yet when starting the TI debugger I get the error as circled in red below .. any idea what the reason is?

  • 0 in reply to Marco Marder
    TI__Mastermind 39755 points

    You need to write click the project and enable NOMAIN (A protected memory to do MCU configure) control:

  • 0 in reply to Eason Zhou
    Prodigy 100 points

    Thx that allowed me to disable BSL. Additionally I am pulling BSL_invoke to low. Therefore I assume it is 100% sure bootloader is not entered anymore.

    Still I get the following error messages from Ozone

    I can recover the device by using a "3365.Unlock MSPM0 1.1.pptx" which I found in another E2E Thread. Then I can program the device exactly once with Ozone and debug. On 2. programming the error as above pops up.

    Any ideas?

  • 0 in reply to Marco Marder
    TI__Mastermind 39755 points

    Do you mean after you program the device, you will meet the error right?

    Can you check with a example code. I want to check if the problem is related to the SW or hardware setting. 

    Please share the schematic as the same time.

  • 0 in reply to Eason Zhou
    Prodigy 100 points

    Hello Eason,

    sorry for the long answer time. I made some progress talking to SEGGER .. therefore I think this can be closed.