0
\$\begingroup\$

I am using AT25DF041B SPI Serial Flash Memory with my application and I am confused about protection about sectors.

When I have read the datasheet it says there is a command for the global unprotect. Therefore I am calling this command in the beginning of the code(main file) and then execute my code which includes a few write command. However, then I noticed that one of the my write function cannot write to flash. After that I put the global unprotect function, just above this write function also and it worked. I am a bit perplexed about this, so do I need every time unprotect command before write something or clear sectors? Does flash protect itself after some time automatically?

Link of the datasheet.

Thanks.

\$\endgroup\$
7
  • 1
    \$\begingroup\$ A link to the datasheet would be very helpful. \$\endgroup\$
    – sa_leinad
    Jul 21, 2022 at 13:23
  • \$\begingroup\$ Thanks for the advice. \$\endgroup\$
    – fury
    Jul 21, 2022 at 13:31
  • 1
    \$\begingroup\$ Posting your code would also be helpful solving why your code does not work. We can't guess what's right or wrong with it. \$\endgroup\$
    – Justme
    Jul 21, 2022 at 14:00
  • 1
    \$\begingroup\$ I am not asking related with code actually, I want to learn is logic of the flash handling with the protected sectors. This way I can implement the logic to my code. \$\endgroup\$
    – fury
    Jul 21, 2022 at 14:51
  • \$\begingroup\$ Do you still need help with this or is the case closed? \$\endgroup\$
    – Ilya
    Jul 29, 2022 at 10:55

2 Answers 2

1
\$\begingroup\$

The problem was related to the protection state of the flash. So every time I need to execute a global unprotect execution after waking up from deep sleep mode. Otherwise, write or read commands are being ignored.

\$\endgroup\$
0
\$\begingroup\$

Search the datasheet for WEL (Write Enable Latch) behavior.

Apparently some of the requirements for write transactions are violated at some point in your sw. Not only you must send a complete transaction (address/data, etc), your chip has additional requirements for #CS signal. It must be deasserted on the even byte boundary, otherwise the transaction in cancelled and the WEL is automatically reset to 0, disabling further writes.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Thanks for the comment. Depending my test, flash wakes up as protected after wake up from ultra deep power down state. So probably the problem is that, I need to execute global unprotect after every exit of the ultra deep power down state. \$\endgroup\$
    – fury
    Jul 22, 2022 at 9:04
  • \$\begingroup\$ @fury, how is it a problem, though? Is it affecting your application's performance in any way? Superficially, it looks like the Flash EPROM is trying to do something good for you, in further protecting your data until you're ready to write to it. That protection may not be necessary, accidental writes by bus electrical faults are spectacularly unlikely, but it's not harmful. \$\endgroup\$
    – TonyM
    Jul 22, 2022 at 9:31
  • \$\begingroup\$ @TonyM the problem was, I didn't know flash acts like that after wake up from sleep, therefore; because my application uses bootloader I would not able to over the air update. Hence simply I cannot write the my application the external flash for the update. But now I learned this behavior and will change my code towards that trajectory. \$\endgroup\$
    – fury
    Jul 22, 2022 at 9:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.