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.

TMS320F28335: Verify issues

Part Number: TMS320F28335

Hello,
customer is programming the F28335 in production over the bootloader and the flash API v2.10 which is loaded into the RAM and then flashing the firmware. After code verification 1% of the device returns „STATUS_FAIL_VERIFY“. Further failure messages are: FirstFailAddr, ExpectedData und ActualData. Nevertheless it seems that the programming was ok and the device is running well. But customer still worries about the message and change the F28335 with a new one because he fears failures in the field later. What could be the reason for this verified failed messages?

Regards, Holger

  • Hi,

    The subject matter expert assigned to this thread is out of office this week due to the the US holiday so you may not get a qualified answer until Tuesday or Wednesday next week.  I apologize for the delay.

    Regards,

    Himanshu

  • Holger,

    Based on my understanding of this function, it should be performing a simple read and compare of the specified flash locations that the customer sends to it.  The physical act of programming also does checks in real time that the program succeeded, so the chance that this passes and an immediate read verify failing should be zero.

    Does the API return a value for the FirstFailAddr, ExpectedData and ActualData variables?  We could use these to determine where the API believes there is an issue. 

    Keep in mind that erasing/programming the flash doesn't need the correct flash read wait states programmed, but the verify routine would need these to be correct(I believe it is WS = 3 for 150MHz), else the access time to the flash would be violated.  Can customer ensure that the the WS are set correctly as they would be in their code execution environment(when they do not see the issue).

    Best,

    Matthew 

  • Hello Matt,
    where in the code has the WS to set?

    Regards, Holger

  • Holger,
    We include this in the DSP2833x_SysCtrl.c on line 111.  It looks like at 150MHz 5WS is required to meet timing.  

    Best,

    Matthew

  • Hello Matt,
    wait states should be ok at customer side:
      #define TGTSYSCLK  100             //see DevInit.c Func. vDeviceInit()
       //Set the Paged Waitstate for the Flash
       FlashRegs.FBANKWAIT.bit.PAGEWAIT = 3;
       //Set the Random Waitstate for the Flash
       FlashRegs.FBANKWAIT.bit.RANDWAIT = 3;
       //Set the Waitstate for the OTP
       FlashRegs.FOTPWAIT.bit.OTPWAIT = 5;

    Here the failure messages:
      Flash_Verify Error 40 FirstFailAddr $00318BAE ExpectedData $8BAE ActualData $8BAE
      Flash_Verify Error 40 FirstFailAddr $003106A3 ExpectedData $06A3 ActualData $06A3
      Flash_Verify Error 40 FirstFailAddr $003005FE ExpectedData $05FE ActualData $05FE
      Flash_Verify Error 40 FirstFailAddr $00320761 ExpectedData $06A6 ActualData $06A6

    The Flash API doc says (page 38):
    Error 40 - STATUS_FAIL_VERIFY - The verify operation failed because one or more bits did not macht the reference data. Try increase the flash or OTP wait states.

    Any idea? I will suggest to the customer to increase the wait states even the look ok.

    Regards, Holger

     

  • Holger,

    That's a good idea, to try to increase the WS to see if this changes things.  The odd thing is that the verify fail is also show that the expected and read data are the same, yet it is giving a failure.  Based on the Flash API documentation it doesn't appear that the verify read is any stricter than a normal read.  I'm going to ask a few other C2000 folks if they have seen this behavior to better understand how this could happen.

    Best,

    Matthew

  • Hello,
    customer did some further evaluation:
    - flashing and verification is correct with CCS and FlashAPIInterface28335V2_10.out
    - customer gets a status 40 error when flashing with customer-flash-programm with WS = 3-3-5 (use of Flash28335_API_V210.lib)
    - flashing and verification is correct when flashing with customer-flash-programm with WS = 5-5-8 (use of Flash28335_API_V210.lib)

    they use a 25MHz crystal, SYSCLK=100MHz, DIVSEL=2, PLLCR=8

    Regards, Holger

    pack.zip

  • Thanks Holger,

    It looks like v210 is the latest Flash API version so that is good.  I'm still looking into how the verify operation is reading the flash vs a normal read.  

    Can you comment on the first bullet point:

    - flashing and verification is correct with CCS and FlashAPIInterface28335V2_10.out

    Does this mean that using the CCS flash tools, don't have this issue, but the API does?  Just want to make sure I'm understanding correctly.  I'll look at that interface to see what parameters it takes in.

    Best,

    Matthew

  • Hello Matt,

    > Does this mean that using the CCS flash tools, don't have this issue, but the API does?
    correct. I thought the flash lib is the same. Then there must be a different in the configuration.

    Regards, Holger

  • Hello Matt,
    customer did a verify (w/o programming) with a faulty unit in CCS. The verify was successful w/o failure message. So the unit is ok. There is some strange thing with the customer programming/verification program. I copied the program in the attachment.

    Regards, Holger

  • Holger,

    I downloaded the coff file and am looking at it.  If we need to look at C source I'll reach out to you via email so we don't have to post here.

    Best,

    Matthew