Pico Fido flashing crashed when using ESP32 Flasher #77
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I'm reporting serious issue which just happened to me.
My device is Waveshare ESP32-S3-Zero. The host machine is Linux, web browser - Chrome.
I started flashing process using online ESP32 Flasher (https://www.picokeys.com/esp32-flasher). The flashing process was going well but stuck at info "wrapping up" for several minutes. I've checked the browser console. Here are the logs:
Now the device seems to be dead - no led lights, nothing when connecting to USB. Here are dmesg logs when I connect it to USB:
What can I do to make it alive again..? help, please.
You can put it in DFU mode and try flashing through espressif tools.
After I kept pressed BOOT + RESET buttons, then released RESET, the board became again visible to OS as serial / uart. Then I flashed it with success with online ESP32 Flasher. No more error during that process.
However, now when I plug it to my Linux machine I still get the same dmesg messages as previously:
Is this a normal behaviour?
Next I tried to use online Pico Commisioner (https://www.picokeys.com/pico-commissioner/) but without success.. :( the device is not accessible.
After flashing, is it listed by
lsusb?No it isn't.
After pressed BOOT + RESET and releasing RESET it appears as serial / uart.
This is normal. Then you have to flash it. After flashing the image, do you see it at
lsusb?No, after successful flashing I don't see it at
lsusb.By default should appear with VID/PID FFFE:FDFC. If it doesn't appear, it might have some problem with USB stack. Which board do you use?
I have Waveshare ESP32-S3-Zero.
I have the same. I'd recommend to use Espressif tools to avoid any problem from the browser.
Ok, so you recommend to clone repo and build from the source, right?
It would be nice, but you can try first downloading the firmware from here https://github.com/polhenarejos/polhenarejos.github.io/blob/main/esp/fw/pico_fido_esp32-s3_6.0.bin
and upload it to your board. If it does not work (very strange), then you can try building it. I use VSCode but you can install the tools standalone:
Thanks. I'll try in the afternoon and let you know.
Ok, so I downloaded the bin firmware from the link you provided.
Here is the flash command I used:
The command result was success:
But the final behaviour is the same - I got the same messages in
dmesg:and the device is not visible in
lsusb:(.I also tried to build
pico-fidofrom sourcebut build process fails:
You have to use the
developmentbranch.Ok, build succeded. Thanks for the tip.
But result is still the same..
Here are the logs:
Did you reset after upload? It says “waiting for download” which means it is still in DFU.
Yes, I did. After reset it is not discoverable in
lsusbunless I put it in DFU mode.A bad board could be an option. The next I'd do is trying one official example from here:
https://github.com/espressif/esp-idf/tree/master/examples/peripherals/usb/device/
tusb_hidis a good choice.The board is ok. I've built and run examples
hello_world,blink.Following your advice I've build and flashed with
tusb_hid. And it's working, here isdmesgoutput:The example works as intended - it moves the cursor on host machine.
Ok, one more observation..
I've managed to build from the source pico-hsm and flashed the board. And it is discoverable after flashing!
Here is
dmesg:and
lsusb:So what's wrong with pico-fido..?
There’s something in the HID descriptors you OS doesn’t like.
Even with Pico HSM your OS is complaining about bInterval parameter but in this case, for whatever reason, it decides continue registering the device. For Pico-fido it decides to abort it but withou any additional information.
Which OS do you use?
Btw make sure your board blinks after reset.
Also it seems you are using a USB3 port. Try using a USB2 port.
Manjaro Linux kernel 6.6.63-1
I don't see any blink of LED on my board..
It's a pity but I don't have any USB2 port.. :(
Same there, im using ESP32-S3 Supermini at development branch on Windows10. No device after flash. Led is blinking. :)
I spotted the problem and fixed. ESP32-S3 has two limitations:
I'll push a fix today.
@polhenarejos keeping fingers crossed it will help :)
I pushed a fix in
development. You can build yourself and try if needed.@polhenarejos I've pulled the code from
developmentbranch and now the board is visible in dmesg, hurray! 😄and in lsusb (I've commisioned it earlier via Pico Commissioner when I had pico-hsm installed):
Huge thanks @polhenarejos ! 👏 Now it's time for testing..
Ok.. so it's better but not perfect.. ;)
If I try to use Yubikey Personalization Tool or WebAuthn site (like webauthn.io) it enters an infinite loop of disconnect -> connect:
Can you pull latest fixes and build it? It might be related with #72
Yes, I've pulled the latest commit (
022503fdc0) fromdevelopmentwith all submodules. Then I build it. For being 100% sure I also erased flash withesptool.py -p /dev/ttyACM0 erase_flash. Then I flashed board with image I had built.But unfortunately, the result is still the same - disconnect / connect loop, when I try to use webauthn.io:
I've tried also with https://www.token2.com/tools/fido2-demo but no success. The behavior is the same - the device is not discovered and "crash loop" begins.
Do you see a light change behavior between these loops? Like switching between red green blue or blinking frequency.
Same, yes, led blinking different colours.
@polhenarejos for me no.. I see no LED light at all :(
Please follow these instructions to generate a coredump https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/kconfig.html#config-esp-coredump-enable-to-flash
pico-fido/pico-keys-sdk/config/esp32/partitions.csv:pico-fido/sdkconfig.defaults:pico-fido/sdkconfig.sdkconfigshould be regenerated.idf.py coredump-infoto retrieve the coredump.Ok, I tried but this is what I got:
Something wrong with
partitions.cvs?Here is the content:
and
sdkconfig.defaults:Ok, then try with this line in
partitions.csv:I've updated
partitions.csvbut the result seems the same:But build seems to respect updated
partitions.csv:Did you flash it correctly? It seems it is taking the old image.
Yes, I suppose.. here is the log of flashing:
I tried on linux, webauthn.io work like a charm on chromium with pico-fido. In windows, crash and bootloop when i try set pin in FIDO2.1 Manager. Try to get coredump, but idf.py gives an error:
Failed to load core dump: Invalid core dump CRC 31b59a50, should be ffffffffThis is new. Can you open a separate issue?
Ok, i try.
@piotr277 I pushed a small change that might block the device. Can you pull, build & try?
@polhenarejos I pulled, build and tried. But it's still the same:
and LED is not working. The behavior at https://www.token2.com/tools/fido2-demo is still the same (infinite loop).
What does it mean:
Core dump version "0xffff" is not supported!?Rebuilt from the development branch and tried to install the pin in ykman under Linux. In this time I get a coredump.
`===============================================================
==================== ESP32 CORE DUMP START ====================
Crashed task handle: 0x3fcecff8, name: 'TinyUSB', GDB name: 'process 1070518264'
Crashed task is not in the interrupt context
Panic reason: ERROR A stack overflow in task TinyUSB has been detected.
================== CURRENT THREAD REGISTERS ===================
exccause 0x0 (IllegalInstructionCause)
excvaddr 0x0
epc1 0x40378e0b
epc2 0x0
epc3 0x0
epc4 0x0
epc5 0x0
epc6 0x0
eps2 0x0
eps3 0x0
eps4 0x0
eps5 0x0
eps6 0x0
pc 0x40375b24 0x40375b24 <panic_abort+16>
lbeg 0x400570e8 1074098408
lend 0x400570f3 1074098419
lcount 0x0 0
sar 0x1c 28
ps 0x60023 393251
threadptr
br
scompare1
acclo
acchi
m0
m1
m2
m3
expstate
f64r_lo
f64r_hi
f64s
fcr
fsr
a0 0x8037a9e0 -2143835680
a1 0x3fcebf70 1070514032
a2 0x3fcebfbc 1070514108
a3 0x3fcebffb 1070514171
a4 0x3fcec1a0 1070514592
a5 0x3fcec180 1070514560
a6 0x3fce9710 1070503696
a7 0x44 68
a8 0x3fc970e0 1070166240
a9 0x1 1
a10 0x44 68
a11 0x804 2052
a12 0x3fcec180 1070514560
a13 0x3fcec160 1070514528
a14 0x3fced9e0 1070520800
a15 0x44 68
==================== CURRENT THREAD STACK =====================
#0 panic_abort (details=0x3fcebfbc "ERROR A stack overflow in task TinyUSB has been detected.") at /opt/esp-idf/components/esp_system/panic.c:466
#1 0x4037a9e0 in esp_system_abort (details=0x3fcebfbc "ERROR A stack overflow in task TinyUSB has been detected.") at /opt/esp-idf/components/esp_system/port/esp_system_chip.c:92
#2 0x4037b88d in vApplicationStackOverflowHook (xTask=0x3fcecff8, pcTaskName=0x3fced02c "TinyUSB") at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:563
#3 0x4037ccd2 in vTaskSwitchContext () at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:3701
#4 0x4037b953 in _frxt_dispatch () at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/portasm.S:451
Backtrace stopped: Cannot access memory at address 0xa5a5a599
======================== THREADS INFO =========================
Id Target Id Frame
1 process 1070518264 panic_abort (details=0x3fcebfbc "ERROR A stack overflow in task TinyUSB has been detected.") at /opt/esp-idf/components/esp_system/panic.c:466
2 process 1070247116 0x400559e0 in ?? ()
3 process 1070518620 0x400559e0 in ?? ()
4 process 1070255820 0x40378e06 in esp_cpu_wait_for_intr () at /opt/esp-idf/components/esp_hw_support/cpu.c:64
5 process 1070253924 0x40378e06 in esp_cpu_wait_for_intr () at /opt/esp-idf/components/esp_hw_support/cpu.c:64
6 process 1070245476 0x400559e0 in ?? ()
7 process 1070512540 0x20000000 in ?? ()
0x3fcecff8 TinyUSB 5/5 4000/92
0x3fcaaccc ipc1 24/24 656/616
0x3fced15c core0 4/4 848/19624
0x3fcacecc IDLE1 0/0 640/888
0x3fcac764 IDLE0 0/0 640/880
0x3fcaa664 ipc0 24/24 656/608
0x3fceb99c Corrupted TCB data
==================== THREAD 1 (TCB: 0x3fcecff8, name: 'TinyUSB') =====================
#0 panic_abort (details=0x3fcebfbc "ERROR A stack overflow in task TinyUSB has been detected.") at /opt/esp-idf/components/esp_system/panic.c:466
#1 0x4037a9e0 in esp_system_abort (details=0x3fcebfbc "ERROR A stack overflow in task TinyUSB has been detected.") at /opt/esp-idf/components/esp_system/port/esp_system_chip.c:92
#2 0x4037b88d in vApplicationStackOverflowHook (xTask=0x3fcecff8, pcTaskName=0x3fced02c "TinyUSB") at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:563
#3 0x4037ccd2 in vTaskSwitchContext () at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:3701
#4 0x4037b953 in _frxt_dispatch () at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/portasm.S:451
Backtrace stopped: Cannot access memory at address 0xa5a5a599
==================== THREAD 2 (TCB: 0x3fcaaccc, name: 'ipc1') =====================
#0 0x400559e0 in ?? ()
#1 0x4037b841 in vPortClearInterruptMaskFromISR (prev_level=) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/include/freertos/portmacro.h:560
#2 vPortExitCritical (mux=0x3fc93cf0 ) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:514
#3 0x4037d9e4 in ulTaskGenericNotifyTake (uxIndexToWait=0, xClearCountOnExit=1, xTicksToWait=) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:5765
#4 0x40375ecc in ipc_task (arg=0x1) at /opt/esp-idf/components/esp_system/esp_ipc.c:62
#5 0x4037b4a8 in vPortTaskWrapper (pxCode=0x40375ea0 <ipc_task>, pvParameters=0x1) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139
==================== THREAD 3 (TCB: 0x3fced15c, name: 'core0') =====================
#0 0x400559e0 in ?? ()
Backtrace stopped: Cannot access memory at address 0x60017
==================== THREAD 4 (TCB: 0x3fcacecc, name: 'IDLE1') =====================
#0 0x40378e06 in esp_cpu_wait_for_intr () at /opt/esp-idf/components/esp_hw_support/cpu.c:64
#1 0x420052b5 in esp_vApplicationIdleHook () at /opt/esp-idf/components/esp_system/freertos_hooks.c:58
#2 0x4037c4d8 in prvIdleTask (pvParameters=0x0) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:4353
#3 0x4037b4a8 in vPortTaskWrapper (pxCode=0x4037c4cc , pvParameters=0x0) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139
==================== THREAD 5 (TCB: 0x3fcac764, name: 'IDLE0') =====================
#0 0x40378e06 in esp_cpu_wait_for_intr () at /opt/esp-idf/components/esp_hw_support/cpu.c:64
#1 0x420052b5 in esp_vApplicationIdleHook () at /opt/esp-idf/components/esp_system/freertos_hooks.c:58
#2 0x4037c4d8 in prvIdleTask (pvParameters=0x0) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:4353
#3 0x4037b4a8 in vPortTaskWrapper (pxCode=0x4037c4cc , pvParameters=0x0) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139
==================== THREAD 6 (TCB: 0x3fcaa664, name: 'ipc0') =====================
#0 0x400559e0 in ?? ()
#1 0x4037b841 in vPortClearInterruptMaskFromISR (prev_level=) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/include/freertos/portmacro.h:560
#2 vPortExitCritical (mux=0x3fc93cf0 ) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:514
#3 0x4037d9e4 in ulTaskGenericNotifyTake (uxIndexToWait=0, xClearCountOnExit=1, xTicksToWait=) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:5765
#4 0x40375ecc in ipc_task (arg=0x0) at /opt/esp-idf/components/esp_system/esp_ipc.c:62
#5 0x4037b4a8 in vPortTaskWrapper (pxCode=0x40375ea0 <ipc_task>, pvParameters=0x0) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139
==================== THREAD 7 (TCB: 0x3fceb99c, name: '') =====================
#0 0x20000000 in ?? ()
======================= ALL MEMORY REGIONS ========================
Name Address Size Attrs
.rtc.text 0x600fe000 0x0 RW
.rtc.force_fast 0x600fe000 0x1c RW A
.rtc_noinit 0x50000000 0x0 RW
.rtc.force_slow 0x50000000 0x0 RW
.iram0.vectors 0x40374000 0x404 R XA
.iram0.text 0x40374404 0xf603 R XA
.dram0.data 0x3fc93b00 0x342c RW A
.flash.text 0x42000020 0x4dfda R XA
.flash.appdesc 0x3c050020 0x100 R A
.flash.rodata 0x3c050120 0x176d8 RW A
.iram0.data 0x40383b00 0x0 RW
.iram0.bss 0x40383b00 0x0 RW
.dram0.heap_start 0x3fca9700 0x0 RW
.coredump.tasks.data 0x3fcaaccc 0x154 RW
.coredump.tasks.data 0x3fcaaa30 0x290 RW
.coredump.tasks.data 0x3fcecff8 0x154 RW
.coredump.tasks.data 0x3fcebeb0 0x1140 RW
.coredump.tasks.data 0x3fced15c 0x154 RW
.coredump.tasks.data 0x3fcb1de0 0x350 RW
.coredump.tasks.data 0x3fcacecc 0x154 RW
.coredump.tasks.data 0x3fcacc40 0x280 RW
.coredump.tasks.data 0x3fcac764 0x154 RW
.coredump.tasks.data 0x3fcac4d0 0x280 RW
.coredump.tasks.data 0x3fcaa664 0x154 RW
.coredump.tasks.data 0x3fcaa3c0 0x290 RW
.coredump.tasks.data 0x3fceb99c 0x154 RW
.coredump.tasks.data 0x20000000 0x70 RW
===================== ESP32 CORE DUMP END =====================
Done!`
Unfortunately it doesn’t show anything meaningful. Can you cmake with
-DCMAKE_BUILD_TYPE=Debugand build it again?All the same...
`===============================================================
==================== ESP32 CORE DUMP START ====================
Crashed task handle: 0x3fcecff8, name: 'TinyUSB', GDB name: 'process 1070518264'
Crashed task is not in the interrupt context
Panic reason: ERROR A stack overflow in task TinyUSB has been detected.
================== CURRENT THREAD REGISTERS ===================
exccause 0x0 (IllegalInstructionCause)
excvaddr 0x0
epc1 0x40378e0b
epc2 0x0
epc3 0x0
epc4 0x0
epc5 0x0
epc6 0x0
eps2 0x0
eps3 0x0
eps4 0x0
eps5 0x0
eps6 0x0
pc 0x40375b24 0x40375b24 <panic_abort+16>
lbeg 0x400570e8 1074098408
lend 0x400570f3 1074098419
lcount 0x0 0
sar 0x1f 31
ps 0x60023 393251
threadptr
br
scompare1
acclo
acchi
m0
m1
m2
m3
expstate
f64r_lo
f64r_hi
f64s
fcr
fsr
a0 0x8037a9e0 -2143835680
a1 0x3fcebf70 1070514032
a2 0x3fcebfbc 1070514108
a3 0x3fcebffb 1070514171
a4 0x3fcec1b0 1070514608
a5 0x3fcec190 1070514576
a6 0x3fcec4f0 1070515440
a7 0x3fcec210 1070514704
a8 0x3fc970e0 1070166240
a9 0x1 1
a10 0x3fcec4f4 1070515444
a11 0x3fcec4f0 1070515440
a12 0x3fcec190 1070514576
a13 0x3fcec170 1070514544
a14 0x3fcec210 1070514704
a15 0x3fcec558 1070515544
==================== CURRENT THREAD STACK =====================
#0 panic_abort (details=0x3fcebfbc "ERROR A stack overflow in task TinyUSB has been detected.") at /opt/esp-idf/components/esp_system/panic.c:466
#1 0x4037a9e0 in esp_system_abort (details=0x3fcebfbc "ERROR A stack overflow in task TinyUSB has been detected.") at /opt/esp-idf/components/esp_system/port/esp_system_chip.c:92
#2 0x4037b88d in vApplicationStackOverflowHook (xTask=0x3fcecff8, pcTaskName=0x3fced02c "TinyUSB") at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:563
#3 0x4037ccd2 in vTaskSwitchContext () at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:3701
#4 0x4037b953 in _frxt_dispatch () at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/portasm.S:451
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
======================== THREADS INFO =========================
Id Target Id Frame
1 process 1070518264 panic_abort (details=0x3fcebfbc "ERROR A stack overflow in task TinyUSB has been detected.") at /opt/esp-idf/components/esp_system/panic.c:466
2 process 1070247116 0x400559e0 in ?? ()
3 process 1070518620 0x400559e0 in ?? ()
4 process 1070255820 0x40378e06 in esp_cpu_wait_for_intr () at /opt/esp-idf/components/esp_hw_support/cpu.c:64
5 process 1070253924 0x40378e06 in esp_cpu_wait_for_intr () at /opt/esp-idf/components/esp_hw_support/cpu.c:64
6 process 1070245476 0x400559e0 in ?? ()
7 process 1070512540 0x20000000 in ?? ()
0x3fcecff8 TinyUSB 5/5 4000/92
0x3fcaaccc ipc1 24/24 656/616
0x3fced15c core0 4/4 848/19624
0x3fcacecc IDLE1 0/0 640/888
0x3fcac764 IDLE0 0/0 640/880
0x3fcaa664 ipc0 24/24 656/608
0x3fceb99c Corrupted TCB data
==================== THREAD 1 (TCB: 0x3fcecff8, name: 'TinyUSB') =====================
#0 panic_abort (details=0x3fcebfbc "ERROR A stack overflow in task TinyUSB has been detected.") at /opt/esp-idf/components/esp_system/panic.c:466
#1 0x4037a9e0 in esp_system_abort (details=0x3fcebfbc "ERROR A stack overflow in task TinyUSB has been detected.") at /opt/esp-idf/components/esp_system/port/esp_system_chip.c:92
#2 0x4037b88d in vApplicationStackOverflowHook (xTask=0x3fcecff8, pcTaskName=0x3fced02c "TinyUSB") at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:563
#3 0x4037ccd2 in vTaskSwitchContext () at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:3701
#4 0x4037b953 in _frxt_dispatch () at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/portasm.S:451
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
==================== THREAD 2 (TCB: 0x3fcaaccc, name: 'ipc1') =====================
#0 0x400559e0 in ?? ()
#1 0x4037b841 in vPortClearInterruptMaskFromISR (prev_level=) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/include/freertos/portmacro.h:560
#2 vPortExitCritical (mux=0x3fc93cf0 ) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:514
#3 0x4037d9e4 in ulTaskGenericNotifyTake (uxIndexToWait=0, xClearCountOnExit=1, xTicksToWait=) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:5765
#4 0x40375ecc in ipc_task (arg=0x1) at /opt/esp-idf/components/esp_system/esp_ipc.c:62
#5 0x4037b4a8 in vPortTaskWrapper (pxCode=0x40375ea0 <ipc_task>, pvParameters=0x1) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139
==================== THREAD 3 (TCB: 0x3fced15c, name: 'core0') =====================
#0 0x400559e0 in ?? ()
Backtrace stopped: Cannot access memory at address 0x60217
==================== THREAD 4 (TCB: 0x3fcacecc, name: 'IDLE1') =====================
#0 0x40378e06 in esp_cpu_wait_for_intr () at /opt/esp-idf/components/esp_hw_support/cpu.c:64
#1 0x420052b5 in esp_vApplicationIdleHook () at /opt/esp-idf/components/esp_system/freertos_hooks.c:58
#2 0x4037c4d8 in prvIdleTask (pvParameters=0x0) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:4353
#3 0x4037b4a8 in vPortTaskWrapper (pxCode=0x4037c4cc , pvParameters=0x0) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139
==================== THREAD 5 (TCB: 0x3fcac764, name: 'IDLE0') =====================
#0 0x40378e06 in esp_cpu_wait_for_intr () at /opt/esp-idf/components/esp_hw_support/cpu.c:64
#1 0x420052b5 in esp_vApplicationIdleHook () at /opt/esp-idf/components/esp_system/freertos_hooks.c:58
#2 0x4037c4d8 in prvIdleTask (pvParameters=0x0) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:4353
#3 0x4037b4a8 in vPortTaskWrapper (pxCode=0x4037c4cc , pvParameters=0x0) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139
==================== THREAD 6 (TCB: 0x3fcaa664, name: 'ipc0') =====================
#0 0x400559e0 in ?? ()
#1 0x4037b841 in vPortClearInterruptMaskFromISR (prev_level=) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/include/freertos/portmacro.h:560
#2 vPortExitCritical (mux=0x3fc93cf0 ) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:514
#3 0x4037d9e4 in ulTaskGenericNotifyTake (uxIndexToWait=0, xClearCountOnExit=1, xTicksToWait=) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:5765
#4 0x40375ecc in ipc_task (arg=0x0) at /opt/esp-idf/components/esp_system/esp_ipc.c:62
#5 0x4037b4a8 in vPortTaskWrapper (pxCode=0x40375ea0 <ipc_task>, pvParameters=0x0) at /opt/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139
==================== THREAD 7 (TCB: 0x3fceb99c, name: '') =====================
#0 0x20000000 in ?? ()
======================= ALL MEMORY REGIONS ========================
Name Address Size Attrs
.rtc.text 0x600fe000 0x0 RW
.rtc.force_fast 0x600fe000 0x1c RW A
.rtc_noinit 0x50000000 0x0 RW
.rtc.force_slow 0x50000000 0x0 RW
.iram0.vectors 0x40374000 0x404 R XA
.iram0.text 0x40374404 0xf603 R XA
.dram0.data 0x3fc93b00 0x342c RW A
.flash.text 0x42000020 0x4dfda R XA
.flash.appdesc 0x3c050020 0x100 R A
.flash.rodata 0x3c050120 0x176d8 RW A
.iram0.data 0x40383b00 0x0 RW
.iram0.bss 0x40383b00 0x0 RW
.dram0.heap_start 0x3fca9700 0x0 RW
.coredump.tasks.data 0x3fcaaccc 0x154 RW
.coredump.tasks.data 0x3fcaaa30 0x290 RW
.coredump.tasks.data 0x3fcecff8 0x154 RW
.coredump.tasks.data 0x3fcebeb0 0x1140 RW
.coredump.tasks.data 0x3fced15c 0x154 RW
.coredump.tasks.data 0x3fcb1de0 0x350 RW
.coredump.tasks.data 0x3fcacecc 0x154 RW
.coredump.tasks.data 0x3fcacc40 0x280 RW
.coredump.tasks.data 0x3fcac764 0x154 RW
.coredump.tasks.data 0x3fcac4d0 0x280 RW
.coredump.tasks.data 0x3fcaa664 0x154 RW
.coredump.tasks.data 0x3fcaa3c0 0x290 RW
.coredump.tasks.data 0x3fceb99c 0x154 RW
.coredump.tasks.data 0x20000000 0x70 RW
===================== ESP32 CORE DUMP END =====================
Done!`
core0is where pico-fido code resides and strangely it is not displayed.What do you do to reproduce it?
I just tried to set the pin right after reflashing: ykman fido access change-pin -n 111111 Previously, webauthn.io offered to set the pin in the browser, now it doesn't. I've reflashed the device several times already.
Reflashing doesn’t clear user space. If set a pin, it is still present. To clean you have to call
esptool.py erase_flashand then flash.I'm always erase flash before reflashing.
Crashed task handle: 0x3fcecff8, name: 'TinyUSB', GDB name: 'process 1070518264'Why task handle and process name in coredump's the same? It is normal?
What do you mean?
Can you increase the stack size?
Change
4096*5by4096*10ate627b3fc86/src/main.c (L345C9-L345C110)development branch coredump when:
ssh-keygen -t ecdsa-sk -C "descr"coredump.txt.gz
Did you increase the stack size ?
previous coredump was with 4096*5, but looks the same with:
coredump.txt.gz
coredumps to UART have to be decoded by yourself, as it depends on the hash of the build and mine and yours differ. Please paste the result of
idf.py coredump-info -c coredump.txtc.txt.gz
I tried with a larger stack size, the coredump output did not change. Now the device does not work at all after reflashing in Linux, when trying to set the pin code in Chromium, the LED blinks orange and green in turn and nothing happens. I managed several times to set pin in Chrome at Windows, after that the device works fine in both Linux and Windows.
Are we increasing the right stack?? IMO stack overflow happens in "TinyUSB" Thread, but we are increasing "core0" stack
Yes, I think it is more likely an stack overflow in my code rather than in TinyUSB.
You can try increase the stack of TinyUSB by adding
to
pico-fido/sdkconfig.defaults. Be sure you removepico-fido/sdkconfigfirst before building.It's work :)
looks better ;)
Is there any hope that someday will be an eddsa firmware for esp32?
Great! Can you check whether
CONFIG_TINYUSB_TASK_STACK_SIZE=6144still works? I'd like to narrow the size as much as possible.Nope. But I tried with unmodified main.c
Which value do you think does it work?
I'm not a coder, but 8192 is work...
6144 is OK here
How it is possible? My device ESP32 S3 Super Mini
Detecting chip type... ESP32-S3
Chip is ESP32-S3 (QFN56) (revision v0.2)
Features: WiFi, BLE, Embedded Flash 4MB (XMC), Embedded PSRAM 2MB (AP_3v3)
Crystal is 40MHz
It is strange. The chipset and memory are the same, defined by the MCU ESP32-S3. Perhaps there's something broken in my code that overflows randomly affecting TinyUSB's stack.
Or someone flashed the old binary, I tried several times... 7168 also works