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

MSPM0L1105: MSPM0 Series IC Programming Issue

YUXUAN CHIANG
Prodigy 225 points

Part Number: MSPM0L1105

Hi Ti Team,

Recently, while testing programming of the NONMAIN region on the MSPM0L1105TRGER, I found that when checking whether the NONMAIN region was blank after an erase operation, the NONMAIN region of this device was not completely erased.

If the erase status cannot be reliably confirmed, this may cause issues when writing data afterward.

 

In addition, I am also testing programming on the MSPM0C1106SRGER.

After programming, I am unable to read back the correct programmed data.

Based on my investigation, it appears that residual data from before programming may still remain inside the IC. 

The correct data can be read only after resetting the IC; however, some customers’ programming files are unable to communicate after an IC reset.

I have also observed that when reading the same address twice, the second read returns the correct data. 

 

Could you please advise how to resolve the issue of incomplete erase on the NONMAIN region of the MSPM0L1105TRGER?

Or is this behavior also related to reading residual internal data that existed before the erase operation?

As for the issue on the MSPM0C1106SRGER where pre-programming residual data is read, is it acceptable to resolve this by reading twice, or is there a more appropriate solution?

Thank you.

Steve.

  • 0
    TI__Mastermind 30965 points

    Hi Steve,

    YUXUAN CHIANG said:
    Recently, while testing programming of the NONMAIN region on the MSPM0L1105TRGER, I found that when checking whether the NONMAIN region was blank after an erase operation, the NONMAIN region of this device was not completely erased.

    Can you share how you program the NONMAIN and read back NONMAIN before prorgam?

    B.R.

    Sal

  • 0 in reply to Sal Ye
    Prodigy 225 points

    Hi Sal,

    I haven’t reached the step of programming the NONMAIN region yet.

    At the moment, I’m only performing erase operations and checking whether the region is blank after erase.

    The erase and read procedures I’m using are based on Chapter 6 of the document at the following link:

    https://www.ti.com/lit/ug/slau847e/slau847e.pdf.

    Thanks.

    Steve.

  • 0 in reply to YUXUAN CHIANG
    TI__Mastermind 30965 points

    Hi Steve,

    So, you are using flashctl to erase NONMAIN and read back in application code?

    If so, I can do some test with EVM board,

    B.R.

    Sal

  • 0 in reply to Sal Ye
    Prodigy 225 points

    Hi Sal,

    Sorry for not clarifying earlier. We are Dediprog, a third-party programming tool vendor.

    I am currently following the procedures described in your TRM to erase and read the NONMAIN region, and integrating this flow into our programming tool.

    Thanks.

    Steve.

  • 0 in reply to YUXUAN CHIANG
    TI__Mastermind 30965 points

    Hi Steve,

    YUXUAN CHIANG said:
    I found that when checking whether the NONMAIN region was blank after an erase operation, the NONMAIN region of this device was not completely erased.

    Can you try read back flash value to see if it is all 0xFF? 

    YUXUAN CHIANG said:
    I have also observed that when reading the same address twice, the second read returns the correct data. 

    Are you reset the STATCMD before a new flashctl operation? Sometimes the CMD status updated later expectation, so you might read back the command pass (which is previous operation status) but actually the new command is on-going.

    YUXUAN CHIANG said:
    I am currently following the procedures described in your TRM to erase and read the NONMAIN region, and integrating this flow into our programming tool.

    There has another useful documents for your reference to develop a programmer tool: https://www.ti.com/lit/an/slaaeo5/slaaeo5.pdf 

    B.R.

    Sal

  • 0 in reply to Sal Ye
    Prodigy 225 points

    Hi Sal,

    Sal Ye said:
    Can you try read back flash value to see if it is all 0xFF? 

    When I tried to read back the data, I found that it was not entirely 0xFF.

    Sal Ye said:
    Are you reset the STATCMD before a new flashctl operation? Sometimes the CMD status updated later expectation, so you might read back the command pass (which is previous operation status) but actually the new command is on-going.

    Since I saw this description in the TRM, does this mean that the issue described there can be resolved by writing 0x00000005h to the CMDTYPE register before each flash operation?

    Sal Ye said:
    There has another useful documents for your reference to develop a programmer tool: https://www.ti.com/lit/an/slaaeo5/slaaeo5.pdf 

    Got it, thank you! I’ll review it again on my side.
     
     
     Thanks. Steve.

  • 0 in reply to YUXUAN CHIANG
    TI__Mastermind 30965 points

    Hi Steve,

    YUXUAN CHIANG said:
    When I tried to read back the data, I found that it was not entirely 0xFF.

    It was strange. If you wait for some time then, how about the read back value? 

    YUXUAN CHIANG said:
    Since I saw this description in the TRM, does this mean that the issue described there can be resolved by writing 0x00000005h to the CMDTYPE register before each flash operation?

    This is not the same thing. The cache can be disbabled by below register:

    You can try if this help.

    YUXUAN CHIANG said:
    Are you reset the STATCMD before a new flashctl operation? Sometimes the CMD status updated later expectation, so you might read back the command pass (which is previous operation status) but actually the new command is on-going.

    This issue is found when CPU clock is higher than 32MHz, maybe this also gives the impact on your implementation.

    YUXUAN CHIANG said:
    Got it, thank you! I’ll review it again on my side.

    I am not the expert on the programmer / debugger tool. Please let me know if you require further help on this issue. I'll talk to internal team expert to see if there any other recommendations.

    B.R.

    Sal