• State
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 2 replies
  • Subscribers 54 subscribers
  • Views 296 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.

Programming MSPM0 devices with XDS110 probe in Code Composer Studio - related question

Chris Yorkey
Genius 14805 points
Other Parts Discussed in Thread: SYSCONFIG

Team,

 Our customer is developing with MSP M0 (G3507) and...

We have additional questions after troubleshooting:

 1. Our bootloader runs from the internal oscillator.  Is the FLASH sensitive to clock configuration, and is there a specific clock speed or setting we should use when reading/writing/erasing FLASH?

2a. We use the APIs DL_FlashCTL_eraseMemoryFromRAM() and DL_FlashCTL_programMemoryFromRAM64WithECCGenerated() to erase and then write memory.  (And as of late we added calls to DL_FlashCTL_readVerifyFromRAM64WithECCGenerated() to verify writes.)  It’s probably also important to verify erases.  Is there an erase-verify API? 

2b. We’re finding that direct memory reads cause the FLASHDED corruption.  Is there a read API?

3.  Does reading memory really cause corruption or is corruption caused by writing to memory that isn’t fully erased?  In the email below I mentioned the debugger showed from the memory dump that some memory cells weren’t fully erased.  Would rerunning the erase API until the erase is verified eliminate corruption events?

4.  Is it possible that the SWD interface and the code that reads memory are interfering with one another, and could this cause FLASH corruption?  If so, is there a way to disable the SWD interface around memory accesses in bootloader, or to disable the SWD interface for bootloader project altogether (but not for the application)?

 5.  Is it possible within the NMI handler to recover from a FLASHDED exception, or is this exception considered a permanent chip failure?

Any input after or before the holidays/New Year is welcomed.

TY,

CY

  • 0
    TI__Mastermind 32845 points

    #1 Customer put the BSL at flash area, make sure to use the latest SDK that we have put our flash operation code into the SRAM. The other point is to configure the flash wait status that the sysconfig will to configure it automatically. 

    #2a first the flash erase API will feedback the command executed statues, if you want to verify it you can read some data in the erased area to verify it.

    #2b No, what's the code you use to read the memory? You can use a pointer to do that.

    #3 The erase will take longer time as below,. How many devices have this issue? Dose customer can provide a simple code that can reproduce this issue?

    #4

    Chris Yorkey said:
    Is it possible that the SWD interface and the code that reads memory are interfering with one another, and could this cause FLASH corruption?

    If you just to read memory, I don't think that will cause any flash memory corruption there. You can disable the SWD to modify the non-main/configuration NVM, or enable it with different password. The TI's BSL do have the command that factory reset to erase the full memory if customer use BSL based on flash memory, this is not work for this case. In this case customer  just can use SWD interface to modify the non-main flash to do the configuration.

    #5 what's the mean of FLASHDED exception? Do you mean flash memory corruption issue?

  • 0 in reply to Gary Gao
    TI__Genius 14805 points

    Hi Gary,

    Thank you.  I know that the customer reviewed your input over the holiday break as well.  I will also forward to you the relevant email thread on topic as well.  In addition:

    Due to project time constraints our customer is considering removing the validation of uC memory from the bootloader for the first production release until this issue can be resolved.  Since their initial bootloader isn’t field upgradable early HW would always have this limitation.  

    They can still produce a FLASHDED exception with the workaround by changing the program counter in the debugger.  So we’ll still need a correction for this issue to know with confidence that events that may cause an unexpected change to the program counter (such as a brown out event or EMI) won’t cause the chip failure.  {OPEN}

    TY,

    CY