ESP32 Forum

Posted: **Mon Aug 13, 2018 5:02 am**

espefuse output is showing:

Identity fuses:
MAC                    MAC Address                                       
  = 30:ae:a4:53:dc:b1 (CRC b2 invalid - calculated 0x3d) R/W

and that causes a fatal error on boot:

Code: Select all

I (659) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
E (669) system_api: Base MAC address from BLK0 of EFUSE CRC error, efuse_crc = 0xb2; calc_crc = 0x3d
abort() was called at PC 0x400dc76b on core 1

Dump is:

Code: Select all

EFUSE block 0:
00000870 a453dcb1 00b230ae 00008000 00000038 00000000 00000004
EFUSE block 1:
00016100 02000003 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE block 2:
00000800 00000000 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE block 3:
00000400 00000000 00000000 00000000 00000000 00000000 00000000 00000000

No flashing has been done on any of those fuses (and anyway BLK0 is pre-flashed by the factory?).

Any idea as to the cause of this? Any way to flash the same MAC (presumably with corrected checksum) to BLK3 to workaround this?

Posted: **Thu Jun 20, 2019 10:38 am**

I have seen this then the ESP was waking up from deepsleep.
Is there some kind of low level issue here! Espressif guys?

The chip was woken on a GPIO:

Code: Select all

    ESP_ERROR_CHECK(esp_sleep_enable_ext0_wakeup(LG_GPIO_PSDOWN, 1));
    esp_deep_sleep_start();

Causing this

Code: Select all

PREAMBLE: This is an ESP32 chip with 2 CPU cores, WiFi/BT/BLE, Heap: 4338708 silicon revision 1
E (162) system_api: Base MAC address from BLK3 of EFUSE version error, version = 255
I (172) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
E (182) system_api: Base MAC address from BLK0 of EFUSE CRC error, efuse_crc = 0x87; calc_crc = 0xce
abort() was called at PC 0x400d6854 on core 0
0x400d6854: esp_efuse_mac_get_default at /Users/fm/amplex/esp-idf/components/esp32/system_api.c:378
.
.
(gdb) bt
#0  0x40098388 in invoke_abort () at /Users/fm/amplex/esp-idf/components/esp32/panic.c:140
#1  0x40098552 in abort () at /Users/fm/amplex/esp-idf/components/esp32/panic.c:149
#2  0x400d6857 in esp_efuse_mac_get_default (mac=<optimized out>) at /Users/fm/amplex/esp-idf/components/esp32/system_api.c:141
#3  0x400d734b in app_main () at /Users/fm/amplex/modules/lora-gridlight/main/lora-gridlight-main.cpp:81
#4  0x400d26a9 in main_task (args=0x0) at /Users/fm/amplex/esp-idf/components/esp32/cpu_start.c:478
(gdb)

Posted: **Thu Jun 20, 2019 11:12 pm**

Hi,

Sorry we never responded to markwj's original post for some reason.

themadsens, I have a couple of questions:

- Does this only happen when waking from deep sleep? If you cycle the power does the ESP32 start correctly from power on reset?
- How is the ESP32 being powered in deep sleep? What voltage range does it run on?

Angus

Posted: **Fri Jun 21, 2019 5:43 am**

Hi Angus. Thanks for replying.

The ESP32 is powered on VDD3P3_RTC by a coin cell throughout the powerdown. We are monitoring the supply with the ULP for going into deepsleep, and then using the same pin as a GPIO for wakeup (as per the code above).

I *might* have seen this on rare occasions without the coin cell. Anyway, I seem to have found a workaround:
It seems to be a sure symptom that the reset reason is RTCWDT_RTC_RESET when this happens, so I cure it by doing a another rollover through deepseleep. Incidentally esp_deep_sleep() seem to be the most reliable way to rollover the chip anyway.

Code: Select all


  int reason = rtc_get_reset_reason(0);
  printf("REBOOT Reason %d (%s) RTC magic: %p\n", reason, lgResetReasonStr(reason), (void*)rtcDataMagic());
  if (RTCWDT_RTC_RESET == reason) {
    // We would experience this: https://esp32.com/viewtopic.php?f=14&t=6743&p=45237#p45237
    printf("BAILOUT: performing deepsleep reset due to spurious RTCWDT_RTC_RESET\n");
    esp_deep_sleep(10);
  }
  uint8_t mac[6];
  if (esp_efuse_mac_get_custom(mac) == ESP_OK) {
    esp_base_mac_addr_set(mac);
  }

Posted: **Mon Jun 24, 2019 11:11 am**

Hi themadsens,

Glad you found a workaround that works.

I think there may be a chance the ESP32 is browning out when coming out of reset (coin cells have high internal resistance so main supply may droop). If you can add additional capacitance to the power supply pins, this may also help.

Angus

Posted: **Mon Jun 24, 2019 11:32 am**

OK, thanks

ESP32 Forum

Corrupt MAC address in efuse

Corrupt MAC address in efuse

Re: Corrupt MAC address in efuse

Re: Corrupt MAC address in efuse

Re: Corrupt MAC address in efuse

Re: Corrupt MAC address in efuse

Re: Corrupt MAC address in efuse