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.

TM4C1294NCPDT: Flash write or erase issue

Part Number: TM4C1294NCPDT

Hi,

I'm using the Tivaware provided library flash access functions, FlashErase() and FlashProgram(), and I'm having a strange issue occasionally happen when writing or erasing. Using the TM4C1294NCPDT processor, we are splitting the flash to employ two partitions to handle an updating scheme. The problem I'm seeing is something appearing to be a memory leak type of issue when either FlashErase or FlashProgram is used. It's inconsistent which function causes it, and it's inconsistent where in the process of updating the other side of flash this happens. The outcome is the program exhibits a failure where all of the "Core Register" values are overwritten to a single value. Sometimes it's something like 0x0000000C (as seen in the provided image), or 0x0004D769, or something else entirely. It's very inconsistent when it happens. I can make a few changes in the code and that can cause the issue to present itself or go away.

This project uses:

  • Code Composer 7.3.0.00019
  • TivaWare 2.1.3.156
  • TI v18.12.6.LTS compiler

I've come across a few e2e forum posts that seem to point at this exact issue. The first is:

In that post, Dmitry is using the same Tiva variant, same version of code composer, etc, and he seems to be having the same problem. Did I miss a suitable resolution to this issue on the forum thread, or was a solution not presented?

The other post is also referenced in that thread, and although it uses a TM4C123 it seems to apply from the description to the problem:

Regards,

Alex

  • Alex Hinton said:
    Did I miss a suitable resolution to this issue on the forum thread, or was a solution not presented?

    I don't believe in that thread a suitable resolution was found.

    From CCS/TM4C129XNCZAD: ROM_FlashErase and ROM_FlashProgram problem at 120MHz a suggestion is to disable the flash prefetch buffer prior to performing flash erase or programming operations, and when the flash operations have been completed re-enable the flash prefetch buffer for performance reasons.

    Since the failure comes and goes with other code changes, it may be worth starting with a program which shows the failure and then manually change the FPFOFF (Force Prefetch Off) bit in the Flash Configuration Register using the debugger around the flash operations to see if that stops the failure.

  • Hello Alex,

    Let me know if Chester's suggestion helps.

    Also you mentioned that the the thread you referenced was the same situation, are you also running an RTOS? If so, do you see any correlation between the issue occurring and a context switch taking place? If not, do you think that maybe an interrupt occurs during that time?

  • Chester and Ralph,

    Thank you both for the prompt replies. First: No, I am not running an RTOS. After reviewing that thread, it seemed like everything else regarding the nature of the problem was similar. I was concerned an interrupt(s) could have been occurring during a flash erase or write operation. However, due to the inconsistent nature of the issue I wanted to cover all my bases and try to find some kind of solution before diving into disabling interrupts.

    Second: Regarding your suggestion Chester, I unfortunately must have missed that thread while scouring the forums the last few days. I appreciate your tip for changing the FPFOFF bit manually through the debugger and was able to complete a very positive test. I got the project into its "failure" state, where the memory overwrite error would occur while running the project. After setting a breakpoint just before the first flash erase operation,  I was able to run and restart the program 10 times. Half of those, I manually set the FPFOFF (Force Prefetch Off) bit as you suggested, and all 5 times it progressed through erasing the flash blocks and writing the new data. The other half of the tests, it ran to the same breakpoint but instead I proceeded past without changing the FPFOFF bit. For all 5 of those, it commenced with erasing only a few blocks before locking up with a similar memory overwrite issue like before.

    After adding this bit setting into the actual project and testing through the rest of yesterday afternoon, I think I can cautiously say this fixed the issue. I appreciate your input on this.

    Lastly, this might be better directed to Ralph. I noticed in the linked thread from Chester that your colleague Bob gave 2 possibilities for the root cause of what's going on. I was wondering if there's been any new insight into what the root cause of this problem is? Are you still thinking it's one of these two things?

    Thank you both again.

    Alex

  • Hi Alex,

    Alex Hinton said:
    Lastly, this might be better directed to Ralph. I noticed in the linked thread from Chester that your colleague Bob gave 2 possibilities for the root cause of what's going on. I was wondering if there's been any new insight into what the root cause of this problem is? Are you still thinking it's one of these two things?

    I circled back with Bob as I hadn't worked an issue like this on my end before, and he did not have any further insights to offer regarding the root cause beyond what was stated in the prior thread.

  • Ralph Jacobi said:
    circled back with Bob as I hadn't worked an issue like this on my end before, and he did not have any further insights to offer regarding the root cause beyond what was stated in the prior thread.

    Is the failure mode considered as a result of a "bug" in the users program, or a possible device errata which should be documented?

  • Hi Chester,

    Provided that what is happening is one of the two ideas that Bob suggested, then it would not be a device errata.