• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 30 subscribers
  • Views 115 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.

MSPM0G3507: The device can't run after programmed by BSL

Robert Chen
Mastermind 9055 points
Part Number: MSPM0G3507

Tool/software:

Hi,

Previously I use XDS110 debugger to program MSPM0G3507 for small quantity production. Now I design a programming machine with BSL mode to program MSPM0G3507 for mass production. The BSL host is another MSPM0G3507. The issue is after the device is programmed, and soldered on target PCB, it can not boot up. It can not be connected by debugger, neither.

Good news is the debugger can connect to target if forced BSL is enabled. With forced BSL, I can review the programmed flash data with XDS110 debugger. So I compare the programmed data with the generated binary file by CCS hex utility. But I can not compare all the data bytes one by one by eyes. So I compare the head, the tail and random positions in between. They are all the same. While programming the device by BSL, the standalone verification step is passed. That means CRC is matched. So I believed all the data are the same.

I also compare the BCR and BSL configuration area with another device programmed by debugger. They are the same... also confirmed they are default values listed in TRM.

Now, the only possibility is the binary file generated by CCS hex utility is incorrect. Is that possible? Well... I also compare the binary data with the data shown on the "Memory Browser" window of CCS after the program is loaded by XDS110. They are the same, at least for the head, the tail and random positions in between.

Now, I have no idea what can do. The BSL programmed device just can't work, and can't be connected by debugger without forced BSL mode.

Any idea?

Robert.

  • 0
    Mastermind 9055 points

    It turns out the issue is caused by the hex utility which removes the 8 padding bytes inserted by the CLang linker before the init sections. The flash memory is defined as a single segment in the linker command file. But the linker still inserts unexpected spaces. When the "image" mode is not enabled in hex utility, those padding bytes are removed. When "image" mode is enabled, they are kept. So, the final output binary files are actually a little bit different.

    I made a mistake when comparing the data. I didn't notice the address is offset by 8 bytes.

    Since we don't know when and why the linker inserts these 8 bytes, it is important to always use the image mode in hex utility. Sure, we also have to create a ROMS directive file for this... a little bit inconvenient.

    That's it.

    Robert.