[EXTERNAL FLASH MEMORY] BLOCK VERIFICATION ERROR - J-Link/J-Flash error

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [EXTERNAL FLASH MEMORY] BLOCK VERIFICATION ERROR - J-Link/J-Flash error

    Hi,

    I would like to ask about help with programming external flash issue.
    Please see attachment! There is a mail with pictures for J-Link/J-Flash/schematic.
    I would like to describe my problem below:

    [SETUP]
    1. J-Link Plus : HW v10.1, 16-36 (YY – WW), V6.30b;
    2. J-Link Base : HW v8.0, 10-04 (YY – WW), V6.30b;
    3. J-Flash - SW V6.30b / J-Link commander - V6.30b;
    4. J-Flash - SW V6.20e / J-Link commander - V6.20e;
    5. NXP LPC1853
    6. WINBOND W25Q128FV – Serial flash memory (DUAL/QUAD SPI)
    7. Keil uVision for ARM


    [PROBLEM]
    We are programming our PCBs since 2016 with J-Link (at first with v8.0 version and SW v.5.X).
    Now we have also the newest J-Link and firmware for that (1. and 2.).

    We programed it more than thousand times (with 3. and 4. and older versions). In 99,5% with success. But sometimes some strange error occur.
    Sometimes during programming process, J-Link can not program external flash (6.).

    There is problem with access to data block – block verification error (see attachment).
    Sometimes it is not a start address of external flash memory but a hundreds bytes later.


    [OUR TEMPORARY SOLUTION]
    Before we used J-Flash or J-Link commander, we had used Keil to program our PCB (with external flash memory algorithm for winbond).
    To “fix” our flash, we have to erase flash by Keil with flash algorithm written by us (.FLM). Very often it doesn’t work for the first time.
    HOW KEIL WORKS : Keil is programming internal NXP memory, and after that, step by step it is coping data from internal memory to external (in the meantime NXP gets new part of data).

    After that, we have access to flash again, and now programming with SEGGER tools and J-Link is possible.
    We tried to reduce programming speed. It doesn’t work.

    [QUESITIONS]
    Could you help us? Do you have any idea what is wrong with our programming procedure?
    It might be a SW/firmware problem, or rather our HW?
    We will be glad for any help.

    Programming external flash memory issue.pdf
    DCWR
  • Hello,

    Thank you for your inquiry.
    Such an issue is not known to us.
    We suspect that this is related to so setup problem as you wrote that it works in over 99% of the cases.

    What happens if you try to program the device again after it got into the "false" state?
    Does the state stay or does the behaviour change?
    Could you read back the memory content? Is the content expected and correct?
    For clarification, what do you mean with "internal NXP memory"? Do you mean RAM?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello,

    What happens if you try to program the device again after it got into the "false" state?
    Does the state stay or does the behaviour change?

    To “fix” our flash, we have to erase flash by Keil with flash algorithm written by us (.FLM). Very often it doesn’t work for the first time.

    Could you read back the memory content? Is the content expected and correct?

    I will try to catch and read memory. Good idea to check the content.

    For clarification, what do you mean with "internal NXP memory"? Do you mean RAM?

    No. I'm talking only about flash memory.
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


    I'm going to investigate this topic much more this weekend. Could you give me any advice? Any idea what is wrong?
  • I have one conclusion.

    If it works properly most the time, and can suddenly failed - and we must reprogram or erase it by Keil flash alghoritm - it means, it is not a HW setup/PCB problem.
    It might be a Flash problem - something latches - or your programming algorithm for that memory is not good enough. It look's like something obvious, but I can not figure out, why it happens during programming, but not in normal working time.

    Please correct me, if I'm wrong.


    DCWR
  • Hello,

    Could you tell us what happens if you try to program the device again with J-Flash after it got into the "false" state?
    Do you get the same error again?

    If it works properly most the time, and can suddenly failed - and we must reprogram or erase it by Keil flash alghoritm - it means, it is not a HW setup/PCB problem.
    It might be a Flash problem - something latches - or your programming algorithm for that memory is not good enough.

    Not necessarily. You wrote that the Keil flash loader fails often as well on first try. So there must be an issue that no flash loader is currently handling properly. This could be due to not documented silicon errors, Flash issues, some trivial setup issue etc. etc.
    Our Flash loader for this device is out for years and this is the first time we hear about an issue like that.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello,

    Can you reproduce this issue on an eval board?
    If yes could you tell us which eval board and what the reproduction steps are?
    Should it not be reproducible on eval hardware the issue is most likely related to your custom board.

    If you don't have eval hardware we can offer you that you send us your board for reproduction and we will take a look at it.
    Should the issue be related to our software/flash loader etc. the investigation will be free of cost.
    Should it be related to your hardware we would have to charge NREs.
    Would such an offer be interesting for you?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi,

    Finally I have a result of our investigation.

    There are some differences between J-Flash and Keil erase algorithms. Espescially if there is problem with flash:
    • J-Flash is using Erase Block (64kB) instruction in opposite to Chip Erease (Keil algorithm);
    • J-Flash does not react when Read Data (after erasing) gives not empty value;
    • J-Flash does not try to Write to Status Register nr 1, in opposite to Keil algorithm
    • J-Flash does not ask about Status Register nr 2;


    I have prepared an excel file with communication comparison between : J-Flash with success, J-Flash with fail and Keil successful try with previously locked memory.
    CommunicationFlow.zip

    I logged it by original Saleae Logic analyzer.

    Flash memory Datasheet:
    pjrc.com/teensy/W25Q128FV.pdf


    Conclusions:
    • There is no HW issue on our side;
    • Your erase algorithm is probably to generic, does not use some commands;


    There is another question, which should be asked to Winbond.

    Why are they responding (flash memory) that, everything is ok after Erase Block command, even if there is no erase operation.


    Best regards,
    DCWR
  • Hi,

    DCWR wrote:

    There are some differences between J-Flash and Keil erase algorithms. Espescially if there is problem with flash:
    That is quite possible as we develop the flash loaders independent from each other.

    DCWR wrote:

    There is no HW issue on our side;

    Your erase algorithm is probably to generic, does not use some commands;
    It still can be a HW issue. Our flash loader will always do the same operation as well as J-Link communication.
    What could be is that the SPI signals are unclean in 1/1000 cases which sets the Flash into a state that is not handled by our flash loader.
    To investigate this we would need a reproduction scenario.
    Could you provide us with one of the boards where the issue appeared and leave the board in the "broken" state.
    We would then take a look at it and see if we can improve the flash algo to handle this special case.

    Would that be an option to you?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.