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

RTOS/PROCESSOR-SDK-AM437X: QSPI erase issue

Rohit Rampa
Intellectual 460 points

Part Number: PROCESSOR-SDK-AM437X

Tool/software: TI-RTOS

Hi,

We have a custom board based on AM437x IDK.

As part of JTAG flashing, I will have to flash U-boot.bin for QSPI boot.

I tried erasing the size of u-boot and also entire memory(64 MB) before writing the u-boot to the QSPI using the flash writer example from the processor SDK..

Post flashing the device, if I perform a reboot, wait of some time(~ 1 min), the device still doesnt boot.

However, if I boot from SD-Card, erase the entire flash memory using the command (sf erase 0x0 0x4000000), remove the sd card, flash the device again(erase before write) using flash writer, the device boots.

Im not able to understand this behaviour.

In the U-boot, I have bypassed EEPROM.

Erase APIs tried: 

gQspiAppFlashWriterObj.length = 0x4000000;
/* Computing the block numbers to be erased */
offsetAddr = 0x0;
startBlockNumber = (offsetAddr / qspiLibInfo.qspiLibFlashInfo.blockSize);
endBlockNumber = (offsetAddr + gQspiAppFlashWriterObj.length) /
qspiLibInfo.qspiLibFlashInfo.blockSize;

for (i = startBlockNumber; i <= endBlockNumber; i++)
{
QSPILibBlockErase(&qspiLibInfo, i);
}

QSPILibChipErase(&qspiLibInfo); // This API also doesnt help.

Kindly help.

Thanks in advance

Rohit

  • 0
    TI__Guru**** 393215 points
    The RTOS team have been notified. They will respond here.
  • 0
    TI__Guru** 116950 points

    Rohit,

    this is a bit surprising as we have been testing Processor SDK RTOS binaries on the AM437x IDK using the flash writer and it seems to be working as expected.

    Is it possible for you to post your package so that we can re-produce this issue at our end. The SF erase command should also be internally invoking the BLOCK ERASE CMD (D8) for the flash device so the behavior should have been identical. Have you tried to read back the contents of the flash after the erase to confirm all of values in the flash are 0xFF  after the erase is complete.?  

    Regards,

    Rahul