• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 142 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.

MSPM0G3107: MSPM0G3107: Flash write causes Default_Handler to be reached when data is read after being written without ECC generation

Camden Smith
Prodigy 10 points

Part Number: MSPM0G3107
Other Parts Discussed in Thread: MSPM0G3507,

I encountered an issue where writing to flash appears successful, but reading the same data causes the system to crash/reach the default interrupt handler.

 

Here we can see that when I write data using DL_FlashCTL_programMemoryFromRAM64, the data is sucessfully written to flash.

DL_FlashCTL_programMemoryFromRAM64(FLASHCTL, u32_dataAddress, u32a_dataArray);

image.png

After this line of code executes, the program jumps to Default_Handler. Sometimes, the program will continue to execute as usual, until I read the data. When I read the data, the program then reaches the Default_Handler. 

To isolate the issue, I tested on an MSPM0G3507 LaunchPad with a stripped-down application (single source file, no RTOS), and the flash operations complete successfully without triggering the default handler.

DL_FlashCTL_unprotectSector(FLASHCTL, MAIN_BASE_ADDRESS, DL_FLASHCTL_REGION_SELECT_MAIN);
gCmdStatus = DL_FlashCTL_programMemoryFromRAM64(FLASHCTL, MAIN_BASE_ADDRESS, &gDataArray64[0]);
 uint64_t *u64p_data = *((volatile uint64_t *)MAIN_BASE_ADDRESS);

When running a similar code sequence on the MSPM0G3507 LaunchPad with RTOS enabled, the program ends up in the Default_Handler again, pointing to the RTOS as the likely culprit.

I eventually found that using DL_FlashCTL_programMemoryFromRAM64WithECCGenerated completely resolves the issue. However, I'm trying to understand why ECC generation is required in this case. I know ECC is best practice for data integrity and error detection, but I'm curious why my simple example works fine on the MSPM0G3507 without ECC and RTOS, yet my MSPM0G3107 application requires it.

  • 0
    TI__Expert 8341 points

    Hi Camden,

    Based on the screenshot you shared, it looks like you are writing to the ECC Corrected region of Flash:

    ECC check is done when reading from Flash in the ECC corrected region. It is unclear what address you are reading from, but if you are reading from the same address you're writing to, this would cause the issue you are seeing, as you are not allowing the HW to generate ECC or manually specifying when writing (unless you use the DL_FlashCTL_programMemoryFromRAM64WithECCGenerated () function call).

    This should not be an RTOS related issue.

    When programming to the ECC corrected region, the data can also be read from the uncorrected region. If you don't want to use ECC, you should make your reads from the uncorrected region.

    Best,

    Owen