In the MQTT software for the ESP8266 (ESP-01 etc), specifically the MAKE file, there is this line..
$(PYTHON) $(ESPTOOL) -p $(ESPPORT) write_flash 0x00000 firmware/0x00000.bin 0x3C000 $(BLANKER) 0x40000 firmware/0x40000.bin
It’s pretty obvious what it does, it blows the two BIN files you’ve just created. By what I don’t understand is why it blows the blanker file at 0x3c000.
No really I’m not losing my marbles. In the MQTT package – in config.c and config.h you’ll learn all about how defaults are stored in FLASH. Specifically 3c000, 3e000 and 3fooo are used to store non-volatile info and if a specific value is not found in the FLASH, then either sector 3c000 or 3e000 is firstly erased programmatically and then over-written – the purpose of using two is to ensure in the event of a failure you always have the previous version – so I cannot for the LIFE of me understand why there is a blanker file for 3c000 AND I can’t understand why 3d000 is not used.
Thought anyone – if someone comes up with some good intel on this I’m moving stuff around…
Peter Scargill
I’m looking at at Ben’s comment… about only 0x3c being blanked… It really does not make sense given that 3c and 3e are used… 3d seems to have been spared use for reasons I really can’t imagine.
So rather than use 3c and 3e with 3f retained just for toggle data, I’m warming to the idea of spreading the load into the 4 segments – no wiping at reload…. as there’s a check number in there if you want to ensure wiping anyway. 3f is not necessary as you can write multiple times to a byte as long as you don’t try to force a zero into a 1.
So in the simplest example the first byte in the block would be 11111111 if unused, 1111110 when writing, 11111100 if valid and 0000000 if done. I’d love someone to confirm that I’m right in saying it is the number of ERASES that limits the life of the FLASH. If that is the case one could keep, say 2k of the block for writing 1 byte or 2 byte logs just writing one at a time from the starting point of ff.
I believe that 0x3c000 is the SDK-default location for storing the wifi presets. Haven’t confirmed this absolutely, but every time I flash new firmware (without flashing 0x3c000), my old wifi settings are preserved. Even when going from the AT firmware to the esp_mqtt firmware. Other addresses eg 0x3d000 might also be SDK defaults for something. I don’t see a downside to just living with these default assignments. Haven’t yet written anything that maxes out the current flash size.
When I flash esp_mqtt, I don’t do the blanking at 0x3c000. Unless I want to start from scratch.
This sort of flash memory is allegedly good for 100,000+ program-erase cycles. Obviously you don’t want to be using them like RAM.
(hit send too soon)
…Obviously you don’t want to be using them like RAM, but there’s lots of latitude for reasonable persistent storage.
I believe the logic here is that you want to blow away the flash where the configuration is stored to force loading the default configuration after a new firmware load. Because you don’t know what was previously stored in that section of flash depending on what firmware was on the chip last.
Interestingly it only blanks 4K at 0x3C or CFG_LOCATION so I would have though it would be pot luck depending on what SAVE_FLAG is currently set to at 0x3F so it probably really should blow away 0x3D as well.
I’m going to keep reading – and if enough people concur, I plan to move the lot elsewhere. What I can’t get my head around is that the first load is a 0000 then there seems to be a WHOLE load of wasted space…. then this possibly un-necessary wipe… and then the code at 4000 – if I knew enough, I’d made it all start at zero and put the non-volatile storage right at the top.