• State Resolved
  • Locked Locked
  • Replies 18 replies
  • Subscribers 84 subscribers
  • Views 959 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.

TMS320F28022-Q1: using Flash program API to program 16 words into Flash but sometimes all 0xFF

Will Gao
Intellectual 2335 points

Part Number: TMS320F28022-Q1

Hi BU, 

Customer uses 2802x_FlashAPI_BootROMSymbols_v2.01.lib to program the Flash of F28022. The process is: Firstly, receive the data package with 16 words (16-bit word, or you can say total 32 bytes); Secondly, programming it into the Flash by calling the Flash APIs as following codes: 

As the fig shown, after programming, they will do verify, but the verification result (i.e. u16VerifyStatus in the codes) will not be used for further judgement or diagnostic. However, the programming status, i.e. u16ProgStatus will be used for further judgement or diagnostic. 

From my view, the above process is totally fine for programming. However, customer finds some chips in their field with following phenomenon. That is some data packages can't be programmed into the Flash, but with results of 0xFFFF, as shown in the following fig. And the similar chip will have different Flash address with this problem in couples of tests, which means the software should be fine. And most importantly, the u16ProgStatus is success in this situation. Since the u16VerifyStatus is not used in customer system, so u16VerifyStatus is not known in this situation. 

Please help analyze the above issue and give your suggestions.

And myself have following doubts and please give your guidance: 

1. why the u16ProgStatus is still success in this situation? what the success status returned by Flash_Program API meaning? It only means the programming commands are successfully released to the Flash state machine? 

2. if it possible the issue is caused by power supply unstable? VDDIO is used to power Flash memory. When VDDIO lower down during programming the Flash contents, could it possible cause the above problem? 

Thanks for your help. 

Regards, 

Will 

  • 0
    TI__Guru* 87155 points

    Hi Will,

    This is assigned to our F28022 flash expert; they will get back to you.

    Thanks and regards,
    Vamsi

  • 0
    TI__Guru* 95315 points

    Will,

                  Is there a reason u16VerifyStatus is not used by the customer?

    Will Gao said:
    2. if it possible the issue is caused by power supply unstable? VDDIO is used to power Flash memory. When VDDIO lower down during programming the Flash contents, could it possible cause the above problem? 

    Can you share the schematics of the power stage with me privately?

  • 0 in reply to Hareesh Janakiraman
    TI__Intellectual 2335 points

    Hareesh, 

    Hareesh Janakiraman said:
    Is there a reason u16VerifyStatus is not used by the customer?

    Because customer thinks the programming status can provide enough information for the last time programming action. And this is why I have doubt that the u16ProgStatus is still success in this situation. Please give your answer for my first question. 

    Hareesh Janakiraman said:
    Can you share the schematics of the power stage with me privately?

    I will request this from customer. But since this issue can only be produced in customer field, i.e. in vehicle test, so the power stage design could be fine from schematic view. From circuit principle, could it be a cause for this issue? 

    Regards, 

    Will 

  • 0 in reply to Will Gao
    TI__Guru* 95315 points

    Will,

         I have requested colleagues more knowledgeable on the API to respond to your first question. 

    Will Gao said:
    I will request this from customer. But since this issue can only be produced in customer field, i.e. in vehicle test, so the power stage design could be fine from schematic view. From circuit principle, could it be a cause for this issue? 

    I don't understand what you are trying to say here. If the device is "current starved" during programming, it could potentially lead to some random errors. 

  • 0 in reply to Hareesh Janakiraman
    TI__Intellectual 2335 points

    Hareesh, 

    My second question is: During programming the Flash with length of 32-byte, if the power supply not stable, e.g. VDDIO down to 3.0V or other value but not BOR/POR the device, will the programming action fail and the contents in Flash still 0xFFFF? 

    I'd like to find the root cause for the issue (sometimes the Flash programming action failed and contents still 0xFFFF), and the power supply may be a possibility. Other analysis direction will also helpful, and please give your guidance, thanks. 

    Regards, 

    Will 

  • 0 in reply to Will Gao
    TI__Guru* 95315 points

    Will,

         This needs to be handled by a Flash API expert. He is currently on vacation and should be back ny Monday. Thank you for your patience.

  • 0 in reply to Hareesh Janakiraman
    TI__Intellectual 2335 points

    Hareesh, 

    Please help pull in this issue's analysis schedule, customer is pushing me to give the response. 

    If power supply is not the cause for this issue, BU side can provide more possibilities and customer can try to replicate it. 

    Thanks & Regards, 

    Will 

  • 0 in reply to Hareesh Janakiraman
    TI__Intellectual 2335 points

    Could it be caused by Flash wrapper logic/memory array transient fault, Just some brain-storming? Do we have met this similar issue before? 

  • +1 in reply to Will Gao
    TI__Guru* 85890 points

    Will,

    In your first post, the picture with the memory windows, does the amount of 0xFF(erased) words correspond to the block size that the customer is programming each time?  Meaning if we to skip a block programmatically we would see this same flash pattern?

    I looked into the API guide, and the program function also performs a verify as part of its routine; so if the contents didn't match it should return an error in real time.

    If no error is returned, it means that program function has verified that the data it was passed was programmed correctly.

    In this case what could that mean:

    1)In the programmation loop we are somehow skipping over a block of flash for some reason; so that the program function doesn't get called.

    2)The program function was passed 0xFF as the buffer to program the flash, and therefore returns a pass

    In terms of how the customer programs their flash, do we know if they erase all the flash before programming, or erase individual sectors as needed?  Do we have the absolute flash addresses that customer sees this issue; as well as the flash sectors that are erased/programmed in their system/flow?

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Intellectual 2335 points

    Hi Matthew, 

    they erase the needed sectors before programming but not the whole Flash. They are not monitoring the Flash address when seeing this issue. 

    MatthewPate said:
    does the amount of 0xFF(erased) words correspond to the block size that the customer is programming each time? 

    Yes, that is correct. The "failed" programming size is the frame block size they each time want to program. So, I agree with you it is more like a flow/frame-receiving problem. 

    But I still want to check with you from failure mode effect analysis (FMEA), if it possible a transient fault in HW could lead to this kind of "failure mode", i.e. programming failed and programming status still ok? Do we meet similar issue before? The reason I need this info is to remove the concerns from customer completely.  

    Thanks & Regards, 

    Will  

  • +1 in reply to Will Gao
    TI__Guru* 85890 points

    Will,

    I have not encountered this kind of issue through a HW fault, both matching the program size as well as returning a value that is erased (0xFFFF). 

    If there were an initial programming issue, as we have said the API would return a fault.

    If there was some time of disturb, I would not expect the the data to be uniform/erased, or confined to a distinct region of words.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Intellectual 2335 points

    Got it. Thank you, Matthew. 

  • 0 in reply to MatthewPate
    TI__Intellectual 2335 points

    Hi Matthew, 

    A further question from customer side: if Flash_program API has already done the verification, why Flash_verify needed? 

    Regards, 

    Will 

  • 0 in reply to Will Gao
    TI__Intellectual 2335 points

    Hi Matthew, 

    could you please reply the above question? 

  • 0 in reply to Will Gao
    TI__Guru* 85890 points

    Will,

    Sorry for the delay, I'm having a conversation on this with some others in the team.  Please expect a reply by tomm here.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Guru* 85890 points

    The difference in the two verification methods are that the verify function uses CPU read to check the contents of the flash against a known image; vs the program function's verify is real time checking that the flash program based on the settings has passed.

    So, in the customer's case, if we believe the issue is likely that the program function was passed all 0xFFFF, the final verify could potentially catch that issue if the correct data was compared against.

    In this case, however, if the verify was done immediately with the incorrect passed value that would have still passed as well.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Intellectual 2335 points

    Hi Matthew, 

    thanks for your reply. How you define " real time checking ", the low level mechanism is still the CPU read to check ? Or using some other HW methods, such as voltage comparator? 

    Regards, 

    Will 

  • +1 in reply to Will Gao
    TI__Guru* 85890 points

    Will,

    The 2nd statement is correct, the "verify" that is being done inside the program function is that the voltage level for the bits that are being programmed for a given word return to the correct level for a programmed bit. 

    So this is relying on some voltage comparison inside the flash to indicate the programmation was successful.

    Best,

    Matthew