• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 88 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-Q1: MSPM0G3507QPTR XDS110 and Promik flashing issue

Cesar Ramirez
Prodigy 35 points

Part Number: MSPM0G3507-Q1
Other Parts Discussed in Thread: MSPM0G3507, UNIFLASH

When MSPM0G3507 is flashed with Promik, the first normal write cycle (via I2C) corrupts our NVM area. That issue does not happen when Lauterbach tools are used. Going further, I have tried to flash some samples with the XDS110, and the results are very similar to those of the Promik tool: the NVM is corrupted on the first write.
Another experiment was: have the full flash made by the Promik tool, confirm NvM corruption, then use Lauterbach to erase only the NvM region. The outcome was NvM recovered, no fail present, and post-writing cycles did not create a corruption condition.

  • 0
    TI__Expert 7955 points

    HI Cesar,

    When you compile your project, the NVM area is likely defined in your source code as an uninitialized or blank data array (filled with 0xFF).

    • The Promik / XDS110 Behavior: These programmers read your binary image and execute a Mass Erase or Sector Erase before flashing. When they see a block containing nothing but 0xFFFFFFFF, standard production optimizations dictate that they skip programming those sectors entirely because an erased flash cell is already naturally 0xFF. A physical hardware erase forces the data array to 0xFF, but it does not calculate or program valid ECC bits into the hidden ECC memory space for those skipped addresses. The ECC bits remain in an unconfigured state.
    • The Lauterbach Behavior: By default, Lauterbach tools use specialized flash programming scripts that explicitly write 0xFF with valid ECC calculated, or they enforce an "Erase-on-Write" policy that cleanly clears the ECC parity matrix synchronously with the sector.
    • The First Write Failure: When your application starts up and attempts its very first active I2C-driven write to that unprogrammed NVM space, the MSPM0 Flash Controller executes a read-modify-write or attempts to program a dirty ECC slot. Because the underlying ECC bits do not match the expected 0xFF parity profile, it triggers an instant hardware ECC Dual-Bit Error (DED) or Single-Bit Error (SEC). This locks up the Flash Controller, resulting in what looks like data corruption or an abort on the first write loop

    Your second experiment perfectly confirms this as the underlying issue. When you used Lauterbach to explicitly target and erase just the NVM region, the Lauterbach driver initialized that sector's flash state and matching ECC parity fields correctly, allowing your application's post-writing cycles to execute without throwing an ECC fault

    Hope this helps!

    -Brian

  • 0
    Prodigy 35 points

    Hi Brian,

    Your explanation is very helpful and totally makes sense to me. Because this issue is on my production line and I'm on the development side, my tool limitation is that I only have the XDS debugger. How can this optimization be mitigated? Can the XDS be configured to avoid skipping the 0xFFFFFFFF parts?

    These are my current settings in UniFlash:

  • 0 in reply to Cesar Ramirez
    TI__Expert 7955 points
    Since you are on the development side, you may have limited control over how the production environment uses the Promik tool. The most robust, production-proof mitigation is to change how your binary image is compiled. By forcing the compiler/linker to explicitly insert actual data blocks instead of "holes" or unallocated spaces, you prevent any smart programmer from optimization bypassing.
    If you are compiling your application using ti-arm-clang, you can modify your post-build steps or configuration file to use the image fill mode:
    1. Open your project properties and find the TI-ARM Linker or Hex Utility options.
    2. Enable the Hex Utility and pass the following arguments to force it to output a contiguous image array:
      1. --image
      2. --fill=0xFFFFFFFF
    3. Ensure your ROMS directive explicitly encapsulates the exact bounds of your NVM storage array

    By compiling the binary this way, the resulting production file physically contains the payload blocks. Both your XDS110 and the production line's Promik tool will see it as structured code data, write to it sequentially, and naturally compute the correct ECC state without any hardware side-effects. Hope this helps!

    -Brian

  • 0 in reply to Brian Dempsey
    Prodigy 35 points

    Thank you for your answer.

    I noticed that I was making a big chunk of S19, so what I did was create partitions:

    And adapted my post-build action: