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

Original question:

TDA4VM: TDA4 Fls Access Mode is INDAC

TDA4VM: Fls Erasing Failed after INDAC writting

Lishuang Du
Prodigy 50 points

Part Number: TDA4VM

     Autosar MemStack is used in TAD4 MCU island. And we use Mcal Fls driver to operate ospi flash. The configurations are as below:

#define FLS_USE_INTERRUPTS             (STD_OFF)

dacEnable = FALSE,

xipEnable = FALSE,

ospiClkSpeed = 133333333U,

dtrEnable = TRUE,

phyEnable = FALSE

    After initialization, the first erasure and writing of data are free of any problems. But after that, when INDAC writing data is completed and erasing is performed again, the following error occurs:

CMD_EXEX_STATUS_FLD is always 1 in OSPI_FLASH_CMD_CTRL_REG. And the CMD in CMD_OPCODE_FLD is WREN.

  • 0
    TI__Mastermind 36307 points

    Hello,

    We've encountered a similar issue before, it was patched around the SDK 8.0 or 8.1 timeframe, I will double-check.

    Can you please tell me which SDK version you are using, in case you are before the fix I can give you a patch for this, otherwise we will need to investigate further.

    Regards,

    Erick

  • 0 in reply to Erick Narvaez
    Prodigy 50 points

    Hi，Erick,

    We use SDK 7.0.  Is it necessary to update the SDK version to solve this problem?

  • +1 in reply to Lishuang Du
    TI__Mastermind 36307 points

    Lishuang,

    I believe this patch actually has not gone into the MCAL yet, but it is available in the PDK. The patch is related to the polling flash status dummy-cycles configuration of this register:

    Here, you can check that the DEVICE_STATUS_NB_DUMMY and let me know what this register value is after initialization. If you see that it is zero (which I suspect is the case), it means it has not been set and is known to have the issue you described above. You can remedy this by setting the dummy cycles based on the datasheet for your flash part. If the flash part is the same as the one on the TDA4VM, it would be 8 dummy cycles:

    "Set the bits 19:16 as 8 in Polling Flash Status Register (offset 0xB0)"

    Let me know if this makes sense and if you can test this fix.

    Regards,

    Erick

  • 0 in reply to Erick Narvaez
    Prodigy 50 points

    Hi，Erick,

        I checked the DEVICE_STATUS_NB_DUMMY and the register value was exactly zero. So I set the number of dummy cycles to 8 after initialization. It really worked. Thank you!

  • 0 in reply to Lishuang Du
    TI__Mastermind 36307 points

    Lishuang,

    Thanks for the confirmation, it helps confirming this bug. Closing this ticket.

    Regards,

    Erick