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.

A strange question using F021 Flash API on F28075

Other Parts Discussed in Thread: CONTROLSUITE

Dear C2K Champs,

We face a strange question using F021 Flash API. The device is F28075 and Flash API from V190 in ControlSuite.

Firstly, the board HW is nor problem, we can run the example code fine.

But when we add the Flash API into the customer's SW, we face this question.

1. When call Fapi_issueAsyncCommandWithAddress to erase Flash

oReturnCheck = Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, (uint32 *)Bzero_Sector_start);

We find that if erasing sector C first, then erase sector D and other, the oReturnCheck = Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, (uint32 *)Bzero_Sector_start); will report there is no source code error or go to illegal area like below picture.

2.When call oReturnCheck = Fapi_doBlankCheck((uint32 *)Bzero_Sector_start, Bzero_16KSector_u32length, &oFlashStatusWord);

It will also report the similar problem like below picture.

Please kindly help to comment and provide suggestions.

Thanks and best regards,

Hardy

  • Hardy,

    It is not an error.  It is just saying that the source file is not found.  Flash API is released as a library and source files are not released and hence you see that message.  

    This message does not affect the API functionality.  You can just step over the API functions instead of stepping in.

    Thanks and regards,
    Vamsi

  • Vamsi,

    I use the step over, but failed and it will report source not find or go to an illeagal area.

    Thanks and best regards,
    Hardy
  • Hardy,

    Did you check if you have erased any source code in Flash that you are trying to execute?

    Thanks and regards,

    Vamsi

  • Hardy,

    Any update on your debug?

    Thanks and regards,
    Vamsi
  • Vamsi,

    Sorry for the late reply. We still don't solve this problem. And we need you continue help on it. Because we copy the code to RAM and run, but it still doesn't finish the flash erasing function.
    So do you have any suggestions? Or which file do you need to check? I can send it to you.

    Thanks and best regards,
    Hardy
  • Hardy,

    1) In the below sample code, where do you have the oReturnCheck and the return assignment code?  It shoul d be in RAM.  Where do you have the while loop checking for the FSM ready?  It should be in RAM.  Can you confirm the same?  Meaning all of the below code should be in RAM.

        // Erase Sector C

        oReturnCheck = Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, (uint32*)Bzero_SectorC_start);

        // Wait until FSM is done with erase sector operation

        while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady){}

    2) In which Flash sector do you have the Flash API?

    3) In which Flash sector do you have the functions that call the Flash API?   

    4) Which sector are you trying to erase?

    Thanks and regards,
    Vamsi

  • Vamsi,

    Yes. After checking code and doing experiments. It is some function is called then to call Flash erase code. The flash sector is C. If we ignore C, it works well. Now the customer is checking the SW code to find out the root cause

    Thanks and best regards,
    Hardy
  • Dear Vamsi,

    Yes, the problem is caused by the code running on the failed sector. But after checking the code and step by step tracking the code, we find that there seems like a compile problem.

    You can find the detailed in below picture.

    You can see the left is C code and the right is ASM code, with single step, we can't understand why there is some GPIO_readpin ASM code cross into the Flash_erase ASM code which causes the earse failed.

    The compiler version is 6.4.4, CCS version is 6.1.3

    Thanks and best regards,

    Hardy

  • Vamsi,

    We encountered a problem in the upgrade process, we found that there is always a random address not write data, resulting in upgrade failure;
    For example, one of the upgrade files is written to: address 0xA7FFF, content 0x55FF, write only one content; because the regional address does not actually write the corresponding value, resulting in correction failure.
    Debugging work done:
    1) Prove that the address can be written:
    When there is data to be written to other addresses, we will rewrite the address to 0xA7FFF, by reading the address online to prove that the address can be normal to write data;
    2) Eliminate program impact
    Because each write to 0xA7FFF address, are not written into, so after debugging each write to 0xA7FFF address, the actual write when the address plus 1, or add 0xF, or to other addresses, can be found Write 0x55FF correctly;
    Question: Are there any addresses that will be restricted?

    Thanks and best regards,
    Xin
  • Hardy,

    I am posting the resolution for this thread (for the benefit of other users) based on multiple meetings that we had on this debug:

    1) Customer used union in the linker command file for the Flash section and that too for code. Union can not be used for Flash memory space. Also, Union should not be used for text section.
    2) Customer did not map the functions in Fapi_UserDefinedFunctions.c file to RAM for execution using .TI.ramfunc section. Hence, those functions in Flash got erased as part of the user application flow.

    Once both the issues got fixed, customer is able to proceed further.

    Thanks and regards,
    Vamsi
  • Xin,

    Is this question related to the debug that I had with Hardy on this post earlier? If not, please start the discussion in a new post.

    Also, I did not understand your question.
    Flash API does not restrict programming any address location in Flash.
    However, when you program ECC, you must program 64-bits at a time for a given 64-bit aligned memory address. Once you program ECC, you can not program those address locations again even if the new data is flipping only the 1s to 0s. This is because the new ECC may collide with the old ECC. Hope this helps.

    If you think i did not answer your question, please start a new thread and explain the issue clearly.

    Thanks and regards,
    Vamsi
  • Dear Vamsi,

    Understand and thanks.

    Thanks and best regards,
    Hardy
  • Dear Vamsi and Xin,

    This is a new question of flash programming.
    I build a new post, let's discuss here:
    e2e.ti.com/.../573745

    Thanks and best regards,
    Hardy