No messages in bootlog when micropython boots.
Hokoshi opened this issue · 2 comments
I applied nina patch to esp-idf-4.4(*1), built micropython 1.17, and wrote to NINA-W106. I don't see the expected message when booting, why? Modify sdkconfig.base like (*2) and get boot log of (*3).
Even with CONFIG_BOOTLOADER_LOG_LEVEL_VERBOSE=y enabled, the expected log(4) does not appear. ubx_ folder is also copied to component.
I think it's a setting on the config side, but could you use the document for that part?
On the other hand, with micropython 1.20, a build error occurs unless ESP-IDF ver5 or higher, so I'm trying with micropython 1.7 this time. I am looking forward to the patch for ESP-IDF ver5.
HoKoR
(*1)
user@rz3900:~/esp$ patch -p2 -i /home/user/esp/u-blox-sho-OpenCPU/NINA-W1-OTP/patches/ubx_phy_cal_esp_idf_4_4.patch -d ./esp-idf-v4.4-with-patch/components/
patching file esp_phy/src/phy_init.c
Hunk #1 succeeded at 435 (offset -42 lines).
patching file esp_wifi/CMakeLists.txt
Hunk #1 succeeded at 32 (offset 1 line).
(*2)
# Bootloader config
# CONFIG_BOOTLOADER_LOG_LEVEL_WARN=y
CONFIG_BOOTLOADER_LOG_LEVEL_INFO=y
# CONFIG_BOOTLOADER_LOG_LEVEL_DEBUG=y
# CONFIG_BOOTLOADER_LOG_LEVEL_VERBOSE=y
# Change default log level to "ERROR" (instead of "INFO")
CONFIG_LOG_DEFAULT_LEVEL_INFO=y
CONFIG_LOG_DEFAULT_LEVEL_ERROR=y
CONFIG_LOG_DEFAULT_LEVEL=2
(*3)
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:0x3fff0030,len:5612
ho 0 tail 12 room 4
load:0x40078000,len:14336
load:0x40080400,len:3672
entry 0x40080674
I (29) boot: ESP-IDF v4.4-dirty 2nd stage bootloader
I (29) boot: compile time 10:48:18
I (29) boot: chip revision: 3
I (32) boot_comm: chip revision: 3, min. bootloader chip revision: 0
I (39) boot.esp32: SPI Speed : 40MHz
I (44) boot.esp32: SPI Mode : DIO
I (49) boot.esp32: SPI Flash Size : 4MB
I (53) boot: Enabling RNG early entropy source...
I (58) boot: Partition Table:
I (62) boot: ## Label Usage Type ST Offset Length
I (69) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (77) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (84) boot: 2 factory factory app 00 00 00010000 001f0000
I (92) boot: 3 vfs Unknown data 01 81 00200000 00200000
I (99) boot: End of partition table
I (103) boot_comm: chip revision: 3, min. application chip revision: 0
I (111) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=30b3ch (199484) map
I (191) esp_image: segment 1: paddr=00040b64 vaddr=3ffbdb60 size=04f50h ( 20304) load
I (199) esp_image: segment 2: paddr=00045abc vaddr=40080000 size=0a55ch ( 42332) load
I (216) esp_image: segment 3: paddr=00050020 vaddr=400d0020 size=116204h (1139204) map
I (625) esp_image: segment 4: paddr=0016622c vaddr=4008a55c size=12180h ( 74112) load
I (655) esp_image: segment 5: paddr=001783b4 vaddr=400c0000 size=00064h ( 100) load
I (656) esp_image: segment 6: paddr=00178420 vaddr=500007f8 size=00818h ( 2072) load
I (677) boot: Loaded app from partition at offset 0x10000
I (677) boot: Disabling RNG early entropy source...
MicroPython v1.17-1973-g9e6885ad8-dirty on 2023-07-30; NINA-W106 with ESP32
Type "help()" for more information.
>>>
(*4)
I (682) phy_init: phy_version 4670,719f9f6,Feb 18 2021,17:07:07
W (682) ubx_phy_cal: No RF calibration value is stored in flash, using 0 (no calibration)
W (692) ubx_phy_cal: rf freq calibration enabled, value_otp = 0(ppm), value_set = 0(8kHz)
W (852) phy_init: saving new calibration data because of checksum failure, mode(0)
I (882) wifi:mode : sta (3c:71:bf:87:e0:94)
I never compiled for micropython, but after reading the repo documentation https://github.com/micropython/micropython/blob/v1.17/ports/esp32/README.md#setting-up-esp-idf-and-the-build-environment v1.17 points to IDF v4.0.2 if one follows their recommendation, if that is the case you probably applied the patch to the wrong IDF installation.
Your sdkconfig is correct and I believe you don’t see the message is because it’s not being compiled, as a quick check you can include #error in one of the files and see if it throws an error, that will confirm if the file is being used or not.
@Hokoshi I assume this fixed the issue so we can resolve it? Otherwise reopen.