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.

MSP430F5436 - Unusable code-space from 0x30000 for 408 bytes.

Hi,

I'm currently encountering an issue on the 5436 where code space from 0x30000 seems to be unreliable for 408 bytes.

In my application, data for initialisation is being stored there (and loaded into memory before main runs).  I find that a fresh controller that has not had power for days can be flashed and run, but after 1+ days of desktop use and debugging (and frequent reflashing) the values stored in this part of memory become unreliable - even after reflashing immediately beforehand.

If I put the board aside for a few days and then re-flash, everything seems to be fine for a while.

Has anyone encountered anything similar?  I can't see anything about this in the errata sheets.

Thanks for your time,

 

Steve

  • Some Further details and corrections:

    It appears to last for more than 408 bytes, not sure entirely how far

    I'm using IAR 4.20 and flashing from the workbench.

    I've encountered this problem on every microcontroller I've flashed often enough since our code grew large enough to reach this address space (4-5 atm).  Brand new, never-previously flashed controllers do not show the problem, but I have every expectation that they will after the usage described above.

    I don't currently have a test app showing this behaviour that I can show other people - my current app relies on parts of our custom firmware, but I believe I could provide one without too much effort (but based on IAR, not code composer studio).

  • I'm also using the Olimex-JTAG-TINY USB flasher.

  • After trying to cause this behaviour on a previously never-flashed microcontroller, the following was performed.

     

    1) flash test app * 2, success.

    2) wait 30 mins

    3) flash test app, fail.

  • I strongly suggest that you perform the "marginal read" immediately after you program it. See if you can fine any Flash bits that are marginally written/erased.

     

  • I strongly suggest that you perform the "marginal read" immediately after you program it. See if you can fine any Flash bits that are marginally written/erased.


  • Thanks for the advice, I'll give this a go, but I have to say the documentation seems to be incomplete:

     

    * The 5 series user guide gives no indication of how the result is indicated from the marginal read mode - does a flash error interrupt fire if a marginal bit is detected?  The documentation is more or less non-existent (mentions that registers exist, register descriptions don't even specify what the difference between mode 0 and mode 1 is, though I gather from further reading that they check for marginal 0s and marginal 1s).

     

    * The 2 series user guide states that the access speed is limited to 1MHz during marginal reads, but no such mention is made in the 5 series guide.  The level of description in the 5 series guide does not leave me confident that this restriction no longer applies, because the entire description of the feature is a mention that it exists and register descriptions.

  • Solution Found:

     

    Using a TI flasher does not produce this problem.  It appears that either IAR or the Olimex flasher is failling to erase memory properly above 0x30000 when they are used together.

     

    Thanks for the suggestion old_yellow_cow

**Attention** This is a public forum