search

espressif / idf-flash-vendor-patches

Project to hold possible patches for flash vendors
Apache License 2.0
3 stars 2 forks source link

hacking xmc lock_sr() to work on IDF 3.3 (IDFGH-7682) #3

Closed phatpaul closed 2 years ago

phatpaul commented 2 years ago

Not sure if I should create a new issue here or continue the discussion here: https://github.com/espressif/esp-idf/issues/7994

I know IDF 3.3 is EOL (not officially supported anymore), but I'm sure I'm not the only one with a mature product based on IDF 3.3 (and legacy make build). I just don't have the time to port my project to IDF 4.x at this time. I have hundreds of products in the field which are at risk of bricking at any time until I can deploy an OTA update with the XMC flash fix lock_sr().

I hacked the code to get it to build and run on IDF 3.3.6. See: https://github.com/espressif/idf-flash-vendor-patches/pull/2

The code runs but doesn't seem to set the status bits permanently.
On each boot I see:

I (44) xmc_sr: Try lock SR permanently.
I (54) xmc_sr: SR3 update: 60 -> 60 (60).
I (54) xmc_sr: SR1 & SR2 update: 0200 -> 0200 (0380).

And esptool.py read_flash_status --bytes 3 still returns Status value: 0x600200

BTW, this is the same result I got before with this code https://github.com/espressif/esp-idf/issues/7994#issuecomment-1126520843 that I based off of an example by community member @winzkigermany . So it seems this official code is essentially the same as the previous community generated solution.

My suspicion is that the flash cache is not actually getting disabled, so the status bytes don't get changed.

phatpaul commented 2 years ago

I'm giving up on this. I took the plunge and upgraded to IDF 4.3...