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.

TMS320F28062 Flash Memory

Hi Everyone,

I'm using flash memory to store calibration values.  I don't have a great understanding of how it all works, but was able to get it to do this properly.  The code enters an auto-calibration mode, takes multiple ADC readings to establish an average, then copies the final values from RAM variables into Flash Sector E.  After power is cycled, those values are copied from Flash back into RAM where they can be easily accessed during normal operation.

It was working in earlier versions of code, but now it doesn't.  I can run through the code in debug mode, and the values are moving appropriately between the RAM memory locations and the debugger reported Flash memory locations.

When I switch to release mode, the calibration values work properly, but after a power cycle, it appears the calibration values are all zeros.  As if it's pulling the values from an unknown location of Flash memory, or they never stored it there in the first place.

While developing this code I ran into difficulties writing to and reading from Flash, but cured the problem by adjusting the compiler optimization level to '0'.  So, it's at zero now.

This phenomenon is present on all copies of hardware, and there are no error messages.

I'm running CCS v 6.1.0.00104, w/C2000 v 6.4.6 TI compiler.

Does anyone have any guidance?  Let me know if you need more detailed information.

  • Hi Robin,

    There are several pieces to your issue.  First, you are taking calibration values and programming them into the flash at runtime.  Second, you are reading the cal values out of the flash and copying them into the RAM for usage at runtime.  I would debug these two problems separately as they are independent, assuming I am understanding what you are saying correctly.

    I guess I'd start with the second problem first.  That is, does the code grab the values from flash and copy them to RAM correctly?  You should be able to debug this  with CCS.  Set a breakpoint(s) at the correct location in your code, and see what it is doing.  I assume you have some pointer to the cal values in flash.  Is the pointer pointing to the correct address?  And so on.

    Then, you can debug the first problem: programming the flash.  You shouldn't try to step through the flash programming library code.  You can step up to it, but then should run through the API call (set a breakpoint after the API call).  I'd first run the frequency test API in the flash API library (see the API documentation) to make sure that is correct.  Then, check the erase call.  Did sector E erase correctly? After that, move on to program.  Do you see the values getting programmed correctly into the flash?

    Also, you are using the terms "Debug mode:" and "Release mode".  These are not modes.  Rather, they are CCS project configurations.  The only differences between these two configurations would be project settings and project files that you set.  For example, some users may want no compiler optimization for debug, and full optimization for release.  You, the user, would need to set this up.  Have you configured any differences between the two configurations?  If so, what are they?  If not, why are you using two configurations?

    All of this should work with the compiler optimizer off.  I'd recommend turning off optimization so you can more easily debug.  You can then turn on optimization later.  Note that since the flash APIs are a pre-built library, if there is a dependency on the optimization level making your code work or fail, the problem is NOT with the flash APIs.  These are not affected by the optimization level you set in your project.

    Good Luck,

    David

  • Hi David,

    Thanks for your response.

    There are several pieces to your issue.  First, you are taking calibration values and programming them into the flash at runtime.  Second, you are reading the cal values out of the flash and copying them into the RAM for usage at runtime.  I would debug these two problems separately as they are independent, assuming I am understanding what you are saying correctly.  <It sounds like you understand correctly.>

    I guess I'd start with the second problem first.  That is, does the code grab the values from flash and copy them to RAM correctly?  You should be able to debug this  with CCS.  Set a breakpoint(s) at the correct location in your code, and see what it is doing.  I assume you have some pointer to the cal values in flash.  Is the pointer pointing to the correct address?  And so on<In debug configuration, I can see the values in Flash and in RAM in the memory browser and by setting watches.  In both cases I can step through code and see them appear when they're supposed to and move when they're supposed to.>

    Then, you can debug the first problem: programming the flash.  You shouldn't try to step through the flash programming library code.  You can step up to it, but then should run through the API call (set a breakpoint after the API call).  I'd first run the frequency test API in the flash API library (see the API documentation) to make sure that is correct.  Then, check the erase call.  Did sector E erase correctly? After that, move on to program.  Do you see the values getting programmed correctly into the flash?  <Sector E erases correctly.  As seen in the memory browser window and in the watches window in debug configuration, the values are getting programmed correctly into the flash.  Do you think I should still pursue the frequency test?>

    Also, you are using the terms "Debug mode:" and "Release mode".  These are not modes.  Rather, they are CCS project configurations.  The only differences between these two configurations would be project settings and project files that you set.  For example, some users may want no compiler optimization for debug, and full optimization for release.  You, the user, would need to set this up.  Have you configured any differences between the two configurations?  If so, what are they?  If not, why are you using two configurations?  <I haven't configured any differences.  I compared them and they look pretty much identical.  Most development/debugging work is done in the debug configuration, because compile/run cycles are much faster, I can step through code and watch variables.  On occasion I switch to release configuration to make sure it still works standalone.>

    All of this should work with the compiler optimizer off.  I'd recommend turning off optimization so you can more easily debug.  You can then turn on optimization later.  Note that since the flash APIs are a pre-built library, if there is a dependency on the optimization level making your code work or fail, the problem is NOT with the flash APIs.  These are not affected by the optimization level you set in your project.  <Optimization is off in both configurations.>

    New news:  The code is storing a struct containing different variables types in Flash.  The integer types are working as expected, but the _iq types are not.  Here's the struct def:

    //rdv Structure for nonvolatile storage of critical variables.
    struct Calibration {
        _iq    dcThresh45;            //rdv  32 bits
        _iq    lfThresh45;            //rdv  32 bits
        _iq    mfThresh45;            //rdv  32 bits
        _iq    hfThresh45;            //rdv  32 bits

        _iq    lfThresh45PP;        //rdv  32 bits
        _iq    mfThresh45PP;        //rdv  32 bits
        _iq    hfThresh45PP;        //rdv  32 bits

        int    GFR_Latch;            //rdv  16 bits
        int    GM_Latch;            //rdv  16 bits
        int    GM_Trip;            //rdv  16 bits
        int    lastGMSStateChange;    //rdv  16 bits

        Uint16    dataWord;        //rdv  Used to test writing and rewriting a single location
    };


    The code 'bit-bangs' the vars out through a GPIO port where I connect a scope to see the bits toggling while running the release configuration code standalone.  I can see the int lastGMSStateChange var coming out of the GPIO port with the expected bit values in release configuration.  That is true of the RAM and Flash versions of that variable.  However, the bit-bang shows all zeros for the _iq vars.  That's true even with code that predates the problem.  In other words code from 6 months ago properly saved and retrieve all these values to and from Flash through power cycles.  So, my current code has the problem, but 6 month old code doesn't.  Bit-banging the var values through GPIO shows zeroes for all _iq vars on both working and non-working code.  Bit-banging the integer variables shows properly written and retrieved values in working and non-working code.

    Please let me know your thoughts.

    Thanks.

  • Robin,

    Robin Vice said:

    <Sector E erases correctly.  As seen in the memory browser window and in the watches window in debug configuration, the values are getting programmed correctly into the flash.  Do you think I should still pursue the frequency test?>

    Probably no need to pursue.

    Robin Vice said:

    <I haven't configured any differences.  I compared them and they look pretty much identical.  Most development/debugging work is done in the debug configuration, because compile/run cycles are much faster, I can step through code and watch variables.  On occasion I switch to release configuration to make sure it still works standalone.>

    If you haven't changed anything in the configurations, I think the default difference is the optimization level for the compiler.  You said the optimizer is off in both configurations however, so someone must have changed this in the Release configuration (default is -O2).  Not sure about other differences.

    In any event, just because you are using the Release configuration doesn't mean you cannot connect with the debugger.  Connect with CCS and debug the code.  Are the structure values correct in RAM?  What goes wrong when you try to bit bang them out?  Sorry, but I don't know what else to suggest.  You will need to debug this using CCS.

    - David

  • Hi David,

    As soon as the write to flash function runs, my debugger hw disconnects.  I'm not able to see what's going on inside the processor after that.

    Anyway, I found the problems.  First of all, the relevant variables that were being bit-banged, were in the _iq type, but I was putting them out as Uint32s.  When I realized that mistake, I multiplied them by the appropriate integer value and they bit-banged properly.  After that, I could see the variables were in fact the correct values in RAM as well as Flash.  So, the Flash read and write routines were working properly.

    Knowing this, I was able to find elsewhere in my code the bone headed maneuver that caused the operability problem.

    Thanks for your participation in my insanity.