AM2432: Flash erase problem after reboot

Andrea Politano said:

is always 0x41

This value matches the flash datasheet.

If you look at the status register 1 from the flash datasheet, the value 0x41h signifies that bits 7 and 0 are set to 1. This means that:

1. Prior program operation failed
2. Device/Flash is not ready to accept new program operations.

Please allow us sometime to comment further.

Hi,

So the status register 1 needs to be continuously polled until the bit value 1 goes back to 0. The bit I am talking about is BUSY Bit,, more formally the RDYBSY bit 0 from status register 1.

The number of tries should be not a fixed value, but atleast few seconds.

For your use case, you can update it as follows:

The waiting time should be max(current number of bytes written, writing to the whole flash) --> so the time taken to write the whole flash + few more seconds, should be the ideal time.

If you understand my explanation, please let me know, so that I can propose this and check with the software development team.

Looking forward to your response.

Regards,
Vaibhav

Hello Vaibhav,

thank you for your reply. I now understand why a long timeout has been chosen for Flash Busy Timeout.

Meanwhile I have a better understanding of what’s happening in my case: power is cut off during a flash block erase operation. When the application restarts, it expects the block to have been successfully erased (because it reads the first bytes as erased), it attempts a write operation but it fails, then it tries to erase the block but it gets stuck in wait.

This is a example of what happens:

status = Flash_offsetToBlkPage(gFlashHandle[0], offset, &blk, &page);
status = Flash_eraseBlk(gFlashHandle[0], blk);
status = Flash_write(gFlashHandle[0], offset, buffer, 1000);
// status = Flash_eraseBlk(gFlashHandle[0], blk); // Here erase operation starts but is not completed because of poweroff
status = Flash_write(gFlashHandle[0], offset, buffer, 1000); // Here the call fails because the application thinks the block has already been deleted, but it hasn't because of poweroff
status = Flash_eraseBlk(gFlashHandle[0],blk);  // Here the application get stuck in wait

For now, I've implemented a solution where, if a write error is detected, I trigger a warm reset. This allows the application to exit the wait loop and, on the next run, clear the block since it detects that the first few bytes were not erased due to the partial write. This seems to solve the problem, but I'm not sure it's the best solution.

Do you have any ideas on how to fix this?

Thank you,

Best Regards,

Andrea

Hi Andrea,

In our drivers, I see that for erase operations, we just simply wait and check for the device busy bit, which means that we poll for when the device, in this case, my external Serial NOR Flash is ready to accept new operations or not.

I would like to know your application flow, because, I am putting forward few questions:

1. When you said power off, is it the power off just during Writes? And then you face this challenge? --> I believe YES.
2. Is the power off just for the SoC or the FLASH or both? --> I think both.

Regards,

Vaibhav