MSPM0L1227: Debugging/Flashing Issues

Part Number: MSPM0L1227
Other Parts Discussed in Thread: UNIFLASH, MSPM0G3507

While debugging our system based on MSPM0L1227 controller we are encountering some strange behavior. Below are steps we followed:

  • first erase MAIN,DATA and NONMAIN(Other wise flashing fails every time)
  • flashed our application using XDS110 debugger and CCS.
  •  The application has a very simple linker file which places application at beginning of FLASH sector. As below:
  • MEMORY

    {

        FLASH              (RX)  : origin = 0x00000000, length = 0x00020000

        SRAM_OS_STACK      (RW)  : origin = 0x20200000, length = 0x00001000

        SRAM_OS_DATA       (RW)  : origin = 0x20201000, length = 0x00001000

        SRAM_TASK1_STACK   (RW)  : origin = 0x20202000, length = 0x00002000

        SRAM_TASK2_STACK   (RW)  : origin = 0x20204000, length = 0x00001000

        SRAM               (RWX) : origin = 0x20205000, length = 0x00003000

        BCR_CONFIG         (R)   : origin = 0x41C00000, length = 0x000000FF

        BSL_CONFIG         (R)   : origin = 0x41C00100, length = 0x00000080

    }

 

Once its flashed, we started a debug session and ran Canoe in parallel to watch LIN communication.

In this first go, LIN works perfectly while in debug mode.

 

After this we stop the simulation remove our debugger and give system a power reset. After this step everything changes. Re-run the software with debugger disconnected and we see no LIN communication.

 

After this point of time there is no further success in LIN communication in both Debugger connected or disconnected.

We tried flashing the sw multiple times but no success in LIN communication.

The only way to recover this is to erase DATA,MAIN and NONMAIN again using Uniflash and flashing app again and the sequence again remains the same as explained above.

 

We tried reading out NONMAIN data in both running(first time) and not running(all the trials after first trial) scenarios.

Looks like BCR and BSL bytes stays uniform all together in all cases.

 

We are suspecting bootloader is not jumping the system into application in second, third and so on run cycle.

 

It would be great to know the reasoning or point at which we went wrong. 

  • Hi, first thing need to do is, between these two condition

    We are suspecting bootloader is not jumping the system into application in second, third and so on run cycle.

    You need to directly connect to your board, without reset the device, in CCS, it called start project-less debug, then connect to M0P core, you will see where CPU PC is.

    And you can also try to load symbol in run, to debug with your C code.

    ---------------------------------

    DAP connect: right click MSPM0G3507.ccxml file in CCS project, start project-less debug, there will factory selection in Run - Load xxx

    -------------------------------

    Try to reproduce the issue, keep the issue, connect to M0P core, then start your boot-app jump debug~

**Attention** This is a public forum