1162-mmu-set-00010000-pos-00010000-esp32-boot-loop

[nskashu2080]

Hello Everyone,
We have many ESP32-WROOM32D, 16 MB modules being used in field. Once such device came back with processor not able to boot.
Our Flash setting is 40MHz, QIO (I think which defaults to DIO). When connected to conole, processor reboots again and again showing 1162 mmu set error.

I found similar issue reported in the link:
https://pcbartists.com/firmware/esp32-f ... op-solved/
"Incorrect Flash Access Setting"

I changed flash setting to 20 MHz and DOUT. Now the processor can boot.

Can anyone help, if my flash setting were wrong or something wrong with my module? How can I confirm the assumption. Thanks..

The boot loop message as shown on console is below:

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0xff001cff,len:1881151
1162 mmu set 00010000, pos 00010000
1162 mmu set 00020000, pos 00020000
1162 mmu set 00030000, pos 00030000
1162 mmu set 00040000, pos 00040000
1162 mmu set 00050000, pos 00050000
1162 mmu set 00060000, pos 00060000
1162 mmu set 00070000, pos 00070000
1162 mmu set 00080000, pos 00080000
1162 mmu set 00090000, pos 00090000
1162 mmu set 000a0000, pos 000a0000
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2

[ESP_Sprite]

Possibly something connected to or conducting gunk on the pads of the module that are connected to internal flash?

[nskashu2080]

This board worked for 1 week. And this issue happened suddenly after 1 week. The module is shielded so I can not check what is inside.. Does this point to a hardware failure?
Also when I change flash setting to lower speed(20 MHz) and DOUT, it starts working..
What should be the recommended setting for Flash?

[ESP_Sprite]

That can happen: for instance, leftover resin/flux around the module paths could attract water, slowly become conductive and when conductive enough mess with the flash signals. Give the board a good scrub in IPA (the chemical not the beer), preferably in an ultrasonic cleaner, to be sure: if it works afterwards, that was your problem. The flash should happily work at 80MHz/QIO in those modules.

[nskashu2080]

Thanks for the suggestion. I tried cleaning the pads with IPA, but it did not solve the problem.
Is there something else that I can try? Should I remove the shield and check something else?
3.3V Power supply to the module is stable..

Another thing, is there a limit to how frequent or max number that we can write to the flash?
After boot up, we write few bytes every minute to the flash.
Could this faillure be bacause of this?

[ESP_Sprite]

In theory, you could damage your flash by writing it too often... Most flash chips are good for 10,000-100,000 cycles. Writing to it every minute (without wear leveling, same location, erasing the sector first) would give you a life time of about a week, worst case scenario.

So the question is: how are you writing to flash? This is important, as most higher-level things in ESP-IDF have some form of wear leveling. For instance, if you use NVS, depending on your configuration, the time to kill the flash may be orders of magnitudes higher, turning weeks into years.

I'm also not terribly sure if this could make the flash die in this specific fashion... Generally, what happens to a flash chip after it's work out is 'undefined', as in not specified by the manufacturer, but the general consensus is that it tends to react in bits stuck at 0 (as in: erasing fails) in the affected region. Assuming you don't write to your app region every minute, I would not expect the behaviour you're seeing from that info.

If you want to do forensics, you could try removing the shield and replacing the flash... if the problem persists, it's clear the flash was the issue.

[Aresby]

All my ESP32s have suddenly (within the last month) refused to work with flash set to qio mode. Setting these to dio solves the problem.

But given that I have always used qio (standard according to Espressif) why the sudden change?

I've had one particular ESP32 project (TTGO v1.7.1 4Mb PSRAM) running for about 1 year using qio mode; a recent update just put it into a continuous loop until I changed it to dio. Something has changed. I wish someone would explain.

[Aresby]

I've posted a new bug report for this issue:
https://github.com/platformio/platform- ... issues/630

[Aresby]

It appears that QIO was being treated as DIO in the ESP platform up until 3.3.0. After that it was interpreted as QIO which none of my boards can support - QOUT being the best they can do.

So it's a bug fix causing regression errors in all of my code. I will have to now go back and set the Flash Mode to QOUT in all my code, check that the board being used actually supports that (reverting to DIO if not) and upload new code so I don't get stung by this at a later date.

[WiFive]

Can you document whether any of your boards have official espressif modules on them or if not which flash chips?