• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 206 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: Can't boot-up after programmed by BSL

Robert Chen
Mastermind 9125 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 binary file generated 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.

Bad news is I have already programmed 500 pcs, none of them works. Now I have to re-program all of them by XDS110 with forced BSL mode.

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

Any idea?

Robert.

  • 0
    TI__Mastermind 25195 points

    Hi Robert,

    You can using compare tools to check the download firmware and readback firmware whether they are totally the same.

    Then, if the same, you can check firstly whether it could work in debug mode with the firmware.

    If it works normal, please check whether the device always go to the bsl mode after power up, which prevents its application code running.

    B.R.

    Sal

  • 0
    Mastermind 9125 points

    I made a mistake when comparing the data shown on the "Memory Browser" window of CCS with the binary data in hex file. I didn't notice the address is offset by 8 bytes at the tail of the binary data. The 8 bytes offset is inserted by Clang linker between sections. When the image mode is disabled in hex utility, these 8 bytes are trimmed. With the image mode enabled and ROMS directive file provided, now it can work.

    There is only one flash memory segment defined in the linker command file. I expect all the program and read-only data sections are continuous allocated. I don't know why the linker splits it as two segments. Since we don't know why and when the linker will insert padding bytes, it is always safer to use image mode while generating hex file.