• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 1475 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.

Flash API Error #31 on TMS320F28335.

Stew Leister43354
Prodigy 80 points

Other Parts Discussed in Thread: TMS320F28335, TMS320F2812

Has anyone seen Flash API Error #31 with the following description?

There was a zero bit error on the Program Operation.

First Fail Address = 0x00338645

Expected Data = 0x0ec8

Actual Data = 0x0ec6

 

The device I am programming is the TMS320F28335.

 

Coded Composer 3.3.82.13

Code generation tools 5.2.2

 

Once this condition is set, it is very difficult to clear.   The only reliable method I have found to clear it is to reprogram the flash with SDFlash.

 

I have experienced this problem with both the DSK and target board.

 

  • 0
    TI__Guru* 93380 points

    Stew Leister said:
    Has anyone seen Flash API Error #31 with the following description?
    There was a zero bit error on the Program Operation.
    First Fail Address = 0x00338645
    Expected Data = 0x0ec8
    Actual Data = 0x0ec6

    Stew,

    An erased flash sector is all 1's (0xFFFF).  When you do a program operation single bits are moved from a 1 to a 0.  Program can be done bit by bit. 

    In order to get any bit back to a 1 an erase operation has to be done - this can only be done by sector though.  That is if you want a 0 moved to a 1 you have to erase the whole sector where the bit is.

    In your example the API is trying to program 0x0EC8 but at least one of these "1" bits has already been changed to a "0" - in this case it is bit 3 so you can't change a 6 to an 8 without first erasing.

    0x6 == 0110

    0x8 == 1000

    Have you seen it on multiple devices?

    Is it consistent?

    If it is consistent and seen on multiple devices then I suspect you are trying to change a value in the flash or could you be over programming something already programmed? 

    -Lori

     

  • 0 in reply to Lori Heustess
    Prodigy 80 points

    Lori,  Thanks for your prompt reply!!   In answer to your questions, Yes I have seen this in multiple devices and no it is not consistent.  Worst of all, it is difficult to clear.  I can erase multiple times using the Code Composer flash tool and still it will persist.   When I erase and program using Spectrum Digital's SD Flash utility it appears to temporarily fix the problem.  However, eventually this condition returns using Code Composer.   ---Stew

     

  • 0 in reply to Stew Leister43354
    TI__Guru* 93380 points

    Stew Leister said:
    Worst of all, it is difficult to clear.  I can erase multiple times using the Code Composer flash tool and still it will persist.   When I erase and program using Spectrum Digital's SD Flash utility it appears to temporarily fix the problem.  However, eventually this condition returns using Code Composer

    Stew,

    Very strange.  I've never heard of a case like this before; I'm not sure what could be causing this behavior. 

    When the error occurs is it always the same address & data?

    Does the problem ever happen if you program with SDFlash instead of Code Composer?  I'm wondering if it is a problem with the plug-in.

    If you look at the address in a memory window after this error has occurred, does the contents read back the same value the API is reporting?

    Can you double check the plug-ins clock configuration - maybe run the toggle test to make sure everything is configured as expected.

    -Lori

     

  • 0 in reply to Lori Heustess
    Prodigy 80 points

    Lori,

     

    Yesterday, I had a chance to learn more detail about this problem.  In answer to your questions:

     

    OSCCLK  = 30Mhz

    DIV = 2

    PLL = 10

     

    I never see this problem when I program with the SDFlash utility.   I also work with the TMS320F2812 device and have not seen this problem when I program this device using the Code Composer flash tool. I only see this when I program the TMS320F28335.

     

    I have checked the address in a memory window after this error has occurred and discovered that sector A was not erased.  All other sectors were erased however.  The addresses for the error naturally occur in sector A.  This is now looking like a sector A erase problem!

     

    When I go back to erase Sector A only and view the memory window, I notice that the tool is having problems erasing the sector.   The diagnostic window displays the run state and almost immediately goes to the halt state.  Eventually, after several tries, the run state displays run for a longer period (approx. 1 sec) after it halts, the sector is erased and I then confirm this with the view the memory window!

     

    Stew

     

  • 0 in reply to Stew Leister43354
    TI__Guru* 93380 points

    Stew Leister said:
    When I go back to erase Sector A only and view the memory window, I notice that the tool is having problems erasing the sector.   The diagnostic window displays the run state and almost immediately goes to the halt state.  Eventually, after several tries, the run state displays run for a longer period (approx. 1 sec) after it halts, the sector is erased and I then confirm this with the view the memory window!

    Stew,

    I'm wondering if a breakpoint is halting the flash programming algo.  Does the plug-in complain about being halted?  Can you try removing all breakpoints before invoking the flash plug-in?

    http://tiexpressdsp.com/index.php/C2000_Flash_Common_Issues/FAQs#Target_Halted_During_Flash_Operation

    -Lori

  • 0 in reply to Lori Heustess
    Prodigy 80 points

    Lori,

     

    Sorry it took so long to reply, but I was on another project  and just got back to this one.

    I think I found the problem!

     

    By removing the GEL file before I program the flash, the problem goes away!!

     

    I did not relize that removing all breakpoints included removing the GEL file as well!

     

    Thanks for your help!

     

    Stew

  • 0 in reply to Stew Leister43354
    Genius 5885 points

    Hi Stew, Lori

     

    The problem that Stew had with GEL file is only with OnFileLoaded function. If within this function there is a call to reset, the CPU is reset after the flash plug-in loads its code but before flash plug-in runs the CPU. This causes that CPU begins executing regular boot code instead of flash algorithm. The flash plug-in relies on CCS to set the PC (program counter) at the beginning (code entry point) of the loaded code. Personally I find this feature of CCS quite annoying as in most embedded systems CPU usually starts from reset (especially while debugging when the reset conveniently puts the CPU into known state and clears any previous settings).

    Regards, Mitja

  • 0
    Prodigy 100 points

    Hello,

    I had the same problem but in my case the reason was different.

    I had a new project with a bad cmd file where a section of text was allocated in the OTP zone.

    So, reading back to this zone failed and it gave me the error Flash API Error #31.

    In my case it was a bad .out file, and I found out looking at the .map file.

    Hope this helps.


    Luca