• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 401 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.

66AK2G12: The procedure to control the QSPI(S25FL512SAGMFI011)

user5968673
Intellectual 430 points
Part Number: 66AK2G12

We use the evaluation board EVMK2G and there is issue when the write to the QSPI.

When executed in the following function order, it does not return to the calling Board_flashWrite ( Step7 ) function.

Please tell the right order to calling the Board_flashWrite function and the cause of issue. 

Step1. Board_flashOpen
Step2. Board_flashEraseBlk 
Step3. Board_flashWrite 
Step4. Board_flashClose
Step5. Board_flashOpen
Step6. Board_flashEraseBlk 
Step7. Board_flashWrite （Issue happen)

Calling the functions in the following order works correctly.

Step1. Board_flashOpen
Step2. Board_flashRead
Step3. Board_flashClose
Step4. Board_flashOpen
Step5. Board_flashEraseBlk
Step6. Board_flashWrite
Best regards.

  • 0
    TI__Guru** 116170 points

    Can you please specify the release version of Processor SDK RTOS and PDK that you are using ? Can you please indicate where does the code hang in Board_flashwrite and if you have looked at the data, cock and chip select pins to see the activity on the pins.

    You have indicated the sequence in the working and the non working case but can you also indicate what sector is the code trying to write and if it is the same sector you erase and wrote to in the previous API calls. It may also help understand the size of writes and the pin behavior during the second write to analyze the issue.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 430 points

    Dear Rahul

    Thank you for your replay.Sorry for lack of information.

    Below is informations of our debug.

    >  the release version of Processor SDK RTOS and PDK
    SYS/BIOS : 6.75.2.00
    k2g PDK : 1.0.14
    > where does the code hang in Board_flashwrite
    ti\pdk_k2g_1_0_14\packages\ti\drv\spi\src\v0\QSPI_v0.c
    Function : QSPI_transfer_v0
    Point : SPI_osalPendLock(object->transferComplete, SemaphoreP_WAIT_FOREVER);

    It looks like the QSPI_hwiFxn_v0 is not called.
    We did below step, add the Step5. there is no issue happened.
    Is there any association the Step5 with issue?

    Step1. Board_flashOpen
    Step2. Board_flashEraseBlk
    Step3. Board_flashWrite
    Step4. Board_flashClose
    Step5. Write  the 0xFFFFFFFF to QSPI_INDIRECT_WRITE_XFER_WATERMARK_REG Register(0x02940074)
    Step6. Board_flashOpen
    Step7. Board_flashEraseBlk
    Step8. Board_flashWrite

  • 0 in reply to user5968673
    Intellectual 430 points

    In reply to Rahul Prabhu:

    Dear Rahul

    Thank you for your replay.Sorry for lack of information.

    Below is informations of our debug.

    >  the release version of Processor SDK RTOS and PDK
    SYS/BIOS : 6.75.2.00
    k2g PDK : 1.0.14
    > where does the code hang in Board_flashwrite
    ti\pdk_k2g_1_0_14\packages\ti\drv\spi\src\v0\QSPI_v0.c
    Function : QSPI_transfer_v0
    Point : SPI_osalPendLock(object->transferComplete, SemaphoreP_WAIT_FOREVER);

    It looks like the QSPI_hwiFxn_v0 is not called.
    We did below step, add the Step5. there is no issue happened.
    Is there any association the Step5 with issue?

    Step1. Board_flashOpen
    Step2. Board_flashEraseBlk
    Step3. Board_flashWrite
    Step4. Board_flashClose
    Step5. Write  the 0xFFFFFFFF to QSPI_INDIRECT_WRITE_XFER_WATERMARK_REG Register(0x02940074)
    Step6. Board_flashOpen
    Step7. Board_flashEraseBlk
    Step8. Board_flashWrite
  • 0 in reply to Rahul Prabhu
    Intellectual 430 points

    Dear Rahul

    Thank you for your replay.Sorry for lack of information.

    Below is informations of our debug.

    >  the release version of Processor SDK RTOS and PDK
    SYS/BIOS : 6.75.2.00
    k2g PDK : 1.0.14
    > where does the code hang in Board_flashwrite
    ti\pdk_k2g_1_0_14\packages\ti\drv\spi\src\v0\QSPI_v0.c
    Function : QSPI_transfer_v0
    Point : SPI_osalPendLock(object->transferComplete, SemaphoreP_WAIT_FOREVER);

    It looks like the QSPI_hwiFxn_v0 is not called.
    We did below step, add the Step5. there is no issue happened.
    Is there any association the Step5 with issue?

    Step1. Board_flashOpen
    Step2. Board_flashEraseBlk
    Step3. Board_flashWrite
    Step4. Board_flashClose
    Step5. Write  the 0xFFFFFFFF to QSPI_INDIRECT_WRITE_XFER_WATERMARK_REG Register(0x02940074)
    Step6. Board_flashOpen
    Step7. Board_flashEraseBlk
    Step8. Board_flashWrite
  • 0 in reply to user5968673
    TI__Guru** 116170 points

    Has this issue been resolved ? I was wondering if you have checked the activity on the data/clock and chip select when the issue occurs. Does this show that the SOC sent the command but the flash is not responding. 

    can you please indicate why the step 5 is executed independent of board flash driver. Does it work when 0x00000000 is written to the register instead (reset value)? Writing to this register definitely impacts the QSPI write functionality. Check the QSPI driver function file QSPI_v0.c which is used by board_flash library to erase, read and write. The SPI transfers will fail since sector size will be smaller than value set the  QSPI_INDIRECT_WRITE_XFER_WATERMARK_REG register

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 430 points

    Dear Rahul

    Thank you for your question.

    Below is my answer.

  • 0 in reply to user5968673
    Intellectual 430 points

    >>Has this issue been resolved ?

    Not yet.

    >>can you please indicate why the step 5 is executed independent of board flash driver.

    I compared the following  2 cases where the problem occurs or not.

    The case of issue happened.
    Step1. Board_flashOpen
    Step2. Board_flashEraseBlk 
    Step3. Board_flashWrite 
    Step4. Board_flashClose
    Step5. Board_flashOpen
    Step6. Board_flashEraseBlk 
    Step7. Board_flashWrite （Issue happen)
    The case of not issue happened.
    Step1. Board_flashOpen
    Step2. Board_flashRead
    Step3. Board_flashClose
    Step4. Board_flashOpen
    Step5. Board_flashEraseBlk
    Step6. Board_flashWrite

    As a result of checking the difference of QSPI register of Board_flashClose step between the two cases, QSPI_INDIRECT_WRITE_XFER_WATERMARK_REG was different. As a result, rewriting the register solved the problem.

    >>Does it work when 0x00000000 is written to the register instead (reset value)?

    Writing 0x00000000 also solves the problem. However, the reset value of the register is described in the following "66AK2Gx multi-core DSP + ARM Keystone II system-on-chip (SOC) TRM (Rev. I) .pdf".

    • QSPI_INDIRECT_WRITE_XFER_WATERMARK_REG Register (Offset = 74h) [reset = FFFFFFFFh]: [0]

    Regards,