RealTimeLogic
Lua Shell does not appear to work on AI-Thinker Boards.
I am attempting to setup with an AI-Thinker board. The chip on these boards is a base model ESP32. The firmware write appears to be successful, but I never get a serial console. Occasionally I get some form of gibberish from the serial port but never anything that resembles a reliable console.
I have tried connecting at both 9600 and 115200 baud rates, if there is a different rate I should try let me know.
@the-maldridge, the default baud rate for legacy esp32 is 115200, does the board use 40Mhz or 26Mhz xtal?
In the console you will see similar output:
idf.py monitor
Executing action: monitor
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP32
--- idf_monitor on /dev/ttyUSB0 115200 ---
Weird, connecting via idf.py works, but screen and tio do not seem to be able to connect.
maldridge@theGibson:~/Desktop/espcam/xedge (devel *%)$ idf.py monitor
Executing action: monitor
Serial port /dev/ttyUSB0
Connecting.........
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32
Running idf_monitor in directory /home/maldridge/Desktop/espcam/xedge
Executing "/home/maldridge/.espressif/python_env/idf5.2_py3.11_env/bin/python /home/maldridge/Desktop/espcam/esp-idf/tools/idf_monitor.py -p /dev/ttyUSB0 -b 115200 --toolchain-prefix xtensa-esp32-elf- --target esp32 --revision 0 /home/maldridge/Desktop/espcam/xedge/build/xedge.elf -m '/home/maldridge/.espressif/python_env/idf5.2_py3.11_env/bin/python' '/home/maldridge/Desktop/espcam/esp-idf/tools/idf.py'"...
--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jul 29 2019 12:21:46
rets Jul 29 2019 12:21:46
rst:0x1 (POWERON_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:0x3fff0030,len:7136
load:0x40078000,len:15780
ho 0 tail 12 room 4
load:0x40080400,len:4
0x40080400: _init at ??:?
load:0x40080404,len:3884
entry 0x40080650
I (31) boot: ESP-IDF v5.2-dev-2383-g82cceabc6e 2nd stage bootloader
I (31) boot: compile time Aug 31 2023 14:36:45
I (33) boot: Multicore bootloader
I (37) boot: chip revision: v3.0
I (41) boot.esp32: SPI Speed : 40MHz
I (46) boot.esp32: SPI Mode : DIO
I (50) boot.esp32: SPI Flash Size : 4MB
I (55) boot: Enabling RNG early entropy source...
I (60) boot: Partition Table:
I (64) boot: ## Label Usage Type ST Offset Length
I (71) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (78) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (86) boot: 2 factory factory app 00 00 00010000 00200000
I (93) boot: 3 storage Unknown data 01 81 00210000 001db000
I (101) boot: End of partition table
I (105) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=970ech (618732) map
I (241) esp_image: segment 1: paddr=000a7114 vaddr=3ff80000 size=00004h ( 4) load
I (241) esp_image: segment 2: paddr=000a7120 vaddr=3ffb0000 size=04378h ( 17272) load
I (251) esp_image: segment 3: paddr=000ab4a0 vaddr=40080000 size=04b78h ( 19320) load
I (260) esp_image: segment 4: paddr=000b0020 vaddr=400d0020 size=12cf4ch (1232716) map
I (518) esp_image: segment 5: paddr=001dcf74 vaddr=40084b78 size=17f94h ( 98196) load
I (558) boot: Loaded app from partition at offset 0x10000
I (558) boot: Disabling RNG early entropy source...
I (569) cpu_start: Multicore app
I (570) quad_psram: This chip is ESP32-D0WD
I (570) esp_psram: Found 8MB PSRAM device
I (572) esp_psram: Speed: 40MHz
I (575) esp_psram: PSRAM initialized, cache is in low/high (2-core) mode.
W (583) esp_psram: Virtual address not enough for PSRAM, map as much as we can. 4MB is mapped
I (592) cpu_start: Pro cpu up.
I (596) cpu_start: Starting app cpu, entry point is 0x40081808
0x40081808: call_start_cpu1 at /home/maldridge/Desktop/espcam/esp-idf/components/esp_system/port/cpu_start.c:224
I (0) cpu_start: App cpu up.
I (1461) esp_psram: SPI SRAM memory test OK
I (1897) cpu_start: Pro cpu start user code
I (1897) cpu_start: cpu freq: 240000000 Hz
I (1897) cpu_start: Application information:
I (1900) cpu_start: Project name: xedge
I (1905) cpu_start: App version: 1
I (1909) cpu_start: Compile time: Aug 31 2023 14:36:27
I (1915) cpu_start: ELF file SHA256: 165ca2b2e...
Warning: checksum mismatch between flashed and built applications. Checksum of built application is 600d1408e02733fd2445e4f3c3bcc6cc1def712c113592768675ba9b213c4509
I (1921) cpu_start: ESP-IDF: v5.2-dev-2383-g82cceabc6e
I (1927) cpu_start: Min chip rev: v0.0
I (1932) cpu_start: Max chip rev: v3.99
I (1937) cpu_start: Chip rev: v3.0
I (1942) heap_init: Initializing. RAM available for dynamic allocation:
I (1949) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (1955) heap_init: At 3FFB6B80 len 00029480 (165 KiB): DRAM
I (1962) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (1968) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1975) heap_init: At 4009CB0C len 000034F4 (13 KiB): IRAM
I (1982) esp_psram: Adding pool of 1005K of PSRAM memory to heap allocator
I (1990) spi_flash: detected chip: generic
I (1993) spi_flash: flash io: dio
W (1998) i2c: This driver is an old driver, please migrate your application code to adapt `driver/i2c_master.h`
I (2009) app_start: Starting scheduler on CPU0
I (2014) app_start: Starting scheduler on CPU1
I (2013) main_task: Started on CPU0
I (2023) esp_psram: Reserving pool of 32K of internal memory for DMA/internal allocations
I (2031) main_task: Calling app_main()
__ __ _
\ \ / / | |
\ V / ___ __| | __ _ ___
> < / _ \/ _` |/ _` |/ _ \
/ . \ __/ (_| | (_| | __/
/_/ \_\___|\__,_|\__, |\___|
__/ |
|___/
LuaShell32 ready.
@the-maldridge, the sequence startup is fine, but the xedge > cursor doesn't show up, Does the monitor console is hang, don't respond to any key press?
I (33) boot: ESP-IDF v5.2-dev-2319-gcbbc7ff9df-dirty 2nd stage bootloader
I (33) boot: compile time Sep 8 2023 12:41:19
I (35) boot: Multicore bootloader
I (39) boot: chip revision: v3.0
I (43) boot.esp32: SPI Speed : 40MHz
I (48) boot.esp32: SPI Mode : DIO
I (52) boot.esp32: SPI Flash Size : 16MB
I (57) boot: Enabling RNG early entropy source...
I (62) boot: Partition Table:
I (66) boot: ## Label Usage Type ST Offset Length
I (73) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (81) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (88) boot: 2 factory factory app 00 00 00010000 00200000
I (96) boot: 3 storage Unknown data 01 81 00210000 001db000
I (103) boot: End of partition table
I (107) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=aec28h (715816) map
I (263) esp_image: segment 1: paddr=000bec50 vaddr=3ff80000 size=00004h ( 4) load
I (264) esp_image: segment 2: paddr=000bec5c vaddr=3ffb0000 size=013bch ( 5052) load
I (270) esp_image: segment 3: paddr=000c0020 vaddr=400d0020 size=127e70h (1212016) map
I (527) esp_image: segment 4: paddr=001e7e98 vaddr=3ffb13bc size=02628h ( 9768) load
I (530) esp_image: segment 5: paddr=001ea4c8 vaddr=40080000 size=1c0a0h (114848) load
I (577) boot: Loaded app from partition at offset 0x10000
I (577) boot: Disabling RNG early entropy source...
I (588) cpu_start: Multicore app
I (589) quad_psram: This chip is ESP32-D0WD
I (589) esp_psram: Found 8MB PSRAM device
I (591) esp_psram: Speed: 40MHz
I (594) esp_psram: PSRAM initialized, cache is in low/high (2-core) mode.
W (602) esp_psram: Virtual address not enough for PSRAM, map as much as we can. 4MB is mapped
I (611) cpu_start: Pro cpu up.
I (615) cpu_start: Starting app cpu, entry point is 0x400817c0
0x400817c0: call_start_cpu1 at /home/jjsch/esp/esp-idf/components/esp_system/port/cpu_start.c:170
I (0) cpu_start: App cpu up.
I (1480) esp_psram: SPI SRAM memory test OK
I (1916) cpu_start: Pro cpu start user code
I (1916) cpu_start: cpu freq: 240000000 Hz
I (1916) cpu_start: Application information:
I (1919) cpu_start: Project name: xedge
I (1924) cpu_start: App version: f16ef5a-dirty
I (1929) cpu_start: Compile time: Sep 8 2023 12:41:09
I (1936) cpu_start: ELF file SHA256: d76f6fd48...
I (1941) cpu_start: ESP-IDF: v5.2-dev-2319-gcbbc7ff9df-dirty
I (1948) cpu_start: Min chip rev: v0.0
I (1953) cpu_start: Max chip rev: v3.99
I (1958) cpu_start: Chip rev: v3.0
I (1963) heap_init: Initializing. RAM available for dynamic allocation:
I (1970) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (1976) heap_init: At 3FFB61E0 len 00029E20 (167 KiB): DRAM
I (1982) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (1989) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1995) heap_init: At 4009C0A0 len 00003F60 (15 KiB): IRAM
I (2002) esp_psram: Adding pool of 1005K of PSRAM memory to heap allocator
I (2011) spi_flash: detected chip: gd
I (2013) spi_flash: flash io: dio
W (2018) i2c: This driver is an old driver, please migrate your application code to adapt `driver/i2c_master.h`
I (2029) app_start: Starting scheduler on CPU0
I (2034) app_start: Starting scheduler on CPU1
I (2033) main_task: Started on CPU0
I (2043) esp_psram: Reserving pool of 32K of internal memory for DMA/internal allocations
I (2051) main_task: Calling app_main()
__ __ _
\ \ / / | |
\ V / ___ __| | __ _ ___
> < / _ \/ _` |/ _` |/ _ \
/ . \ __/ (_| | (_| | __/
/_/ \_\___|\__,_|\__, |\___|
__/ |
|___/
LuaShell32 ready.
>
The monitor console does eventually show up, however, I think idf.py is booting the board because when I try to just supply it with power, it never managed to join the wifi network, and if I hook it up to something like screen it never produces any output.
In most cases USB can power ESP32 boards, especially if you connect sensors or devices to +3V3 or +5V pins, but it depends on the power capacity of the USB port of the PC/Notebook. To connect to Wi-Fi it is necessary to write in the console: esp32.netconnect("wifi", {ssid="xxxxx", pwd="xxxxx"})
Can you share your output console with me?
I (2051) main_task: Calling app_main()
__ __ _
\ \ / / | |
\ V / ___ __| | __ _ ___
> < / _ \/ _` |/ _` |/ _ \
/ . \ __/ (_| | (_| | __/
/_/ \_\___|\__,_|\__, |\___|
__/ |
|___/
LuaShell32 ready.
> esp32.netconnect("wifi", {ssid="AndroidAP", pwd="******"})
Connecting to: AndroidAP
>
ip: 192.168.193.97, mask: 255.255.255.0, gw: 192.168.193.38
Xedge: Server listening on IPv4 port 80
Xedge: SharkSSL server listening on IPv4 port 443
Xedge: Configuration file: /spiflash/xedge.conf: enoent
Sorry, I should have clarified. When using idf.py monitor from inside the xedge source directory, everything works as expected. The board boots, the wifi connection works fine, and I can access the embedded IDE without issue. What does not work is connecting the board to the same port, but without idf.py (so only drawing power). My understanding is that in that case, the image should boot and use the stored network information to join the network and become available remotely. It however does not.
Given that in the fail case there is no console output at all (I continue to suspect that the board simply isn't booting) what console output would you like, specifically?
Thanks for the clarification, you are right, when an adapter (wifi) is successfully configured, the SSID and PSW are stored in flash memory and restored on boot and used to connect, in this case to the wifi network. To ensure that the network parameters are saved, run the console a second time and you will see the adapter connecting after calling app_main().
I (2029) app_start: Starting scheduler on CPU0
I (2034) app_start: Starting scheduler on CPU1
I (2033) main_task: Started on CPU0
I (2043) esp_psram: Reserving pool of 32K of internal memory for DMA/internal allocations
I (2051) main_task: Calling app_main()
Connecting to: AndroidAP
__ __ _
\ \ / / | |
\ V / ___ __| | __ _ ___
> < / _ \/ _` |/ _` |/ _ \
/ . \ __/ (_| | (_| | __/
/_/ \_\___|\__,_|\__, |\___|
__/ |
|___/
LuaShell32 ready.
>
ip: 192.168.193.97, mask: 255.255.255.0, gw: 192.168.193.38
I did some testing with a 3A wall adapter (USB phone charger) and it works.
Given that the board works on the port I'm testing with I think we can rule out power issues. I'm 99% sure this is an issue with the bootloader that is generated from the xedge source tree. Based on my understanding, when using the idf.py application it booloads using a stub loader sent over from the host machine, ignoring the one in flash.
The device you're testing on looks to be an ESP32-S3, does the firmware get checked regularly against classic ESP32 modules?
The image I posted was of a Legacy esp32, not an S3 version, you can verify in the log that it is the same one you have. I (589) quad_psram: This chip is ESP32-D0WD. We regularly test the xedge with both versions of ESP32, the only requirement is 8 megabytes of PSRAM.
If you refere to the idf.py monitor, it does not load any botloader when booting on the esp32, it only sends the reset sequence with the DTR/RTS pins of the serial port, you can emulate this sequence when you connect the board to a USB wall adapter, pressing the reset button.
Additionally, you can use any serial terminal application to test xedge32 log; in this case I will use GTKTerm to display the DTR sequence to reset the device.
https://github.com/RealTimeLogic/Xedge32/assets/55675185/c15d58c8-604c-4a6a-957b-d953e42687dc
If this doesn't work, please send me the link and command that you used to flash the xedge32 bin image on the device.