Demo on esp32-s2 not working

[Bun-Bun2]

I wasn't paying attention and ordered a esp32-s2 dev board by mistake. But thought I would try and get it working anyway.

I added/changed the following in platformio.ini and was able to get the demo project to build and flash to the device. However nothing happens.

Serial monitor shows a bunch of encoded stuff coming back. But WS2812's attached to pin 5 (or any other gpio pin for that matter) does nothing.

[dev_esp32-s2-saola-1]
extends         = base
board           = esp32-s2-saola-1

[env:demo]
extends         = dev_esp32-s2-saola-1
build_flags     = -DDEMO=1
                  -Ofast
                 ${dev_esp32-s2-saola-1.build_flags}

EDIT:

I came back and added monitor_speed = 115200 to the dev_esp32-s2-saola-1 block and now I see the following in the serial monitor.

ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x3 (RTC_SW_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x40026849
SPIWP:0xee
mode:DIO, clock div:1
load:0x3ffe6100,len:0x524
load:0x4004c000,len:0xa70
load:0x40050000,len:0x2958
entry 0x4004c18c
E (213) esp_core_dump_flReplacing Idle Tasks with TaskManager...

assert failed: xTaskGetIdleTaskHandleForCPU tasks.c:2932 (cpuid < 1)


Backtrace: 0x40026e1e:0x3ffcf120 0x40029dc9:0x3ffcf140 0x4002f4b9:0x3ffcf160 0x4002b342:0x3ffcf290 0x400934fc:0x3ffcf2b0 0x40093f92:0x3ffcf2e0 0x4009c68e:0x3ffcf320   




ELF file SHA256: c6eb1ae34b306d60

E (248) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
Rebooting...

Not sure where to go from here in troubleshooting this. I have some proper ESP32 dev boards incoming regardless.

EDIT2:

Maybe it's because S2 only has a single core?

[robertlipe]

As you've now learned, "ESP32" is a family of devices, many without a lot in common, and most with confusing names. Just roaming through.
https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/main/platformio.ini
and spot-checking devices, everything I checked had dual cores.

With no actual knowledge or experience yet, but reading code, it looks like it has a lot going it. It's probably possible to build a configuration that disables some percentage of spiffy features that would work on a single core, especially if you take a reduction in pixels. Take a peek at

NightDriverStrip/src/main.cpp

Line 92 in ec4006f

// A number of worker threads are created which:

and consider building a new configuration with fewer features. Also, acknowledge that you're going to be on a road little traveled and essentially building your own platform (which is cool!) and not really able to rely on others much for help. You'll become the expert on that port, but given the price resistance of "real" ESP32-S3 boards (they're plentiful in the $5-10 USD range) it may be a bit lonely, but there are a LOT of boards in the ESP32C2 class that might benefit from such a configuration. (STM32F403 is about the same class of device and ESP32C3 is RISC-V with FPU, but is also single core.)

You should also be prepared to do minor battle with the hardcoded(ish) pinning of tasks to cores at https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/ec4006f8ad560144778f0c4e11325332a78e5694/include/globals.h#LL204C1-L204C1

Also, if you're pushing a lot of pixels, I'm guessing that the RAM (especially if using flip buffers) for the RGB pixel buffer and some combination of audio, decompression, effects, and network inputs can get crowded if feeding multiple panels. Moving from the 512KB from the S3 to the 320K of the S3 may also lower the max limit of the number of panels or resolution supported.

There are certainly plentiful projects pumping pixels on S2 and even more humble SoCs, so meaningful blinky lights can be reached, but I think you have indeed run into a limit on this exact default combination of this code.

I'd suggest either closing this to a work in progress if you're willing to tackle that or closing it if you choose to flee.

[Bun-Bun2]

Yes, looking deeper I am finding lots of code with the expectation of 2 cores. Thanks for pushing me in the right direction.

I've fixed up main.cpp and taskmgr.h (not elegantly mind you) to function with a single core. However now i've hit a StoreProhibited exception in ledbuffer.h. Progress!

I have and see no real reason for me to use an ESP32-S2. I only got this by mistake from not paying attention to what I was ordering. However, pure curiosity has taken over to see if I can get it at least run the demo code. If not for any other reason than it's walking me through some of the code of the project.

EDIT:

Nevermind, I got it working! commented out psram_allocator lines in ledbuffer.h and now the demo code runs on the ESP32-S2. And here my journey ends I think. I will move on to other boards that I ordered that have no arrived and work without this muckery.

[robertlipe]

While you're ordering an ESP32-S3 (and more panels and more strips and more ....) you should probably add a JTAG probe to your order if you don't have one. That's another device where there's a bit of a startup distraction of learning about cables and OpenOCD and however it's connected in PIO and such, but it's SO worth it when it comes to debugging a crash or the ability to single step through an exception handler or even boot code if you need to do it. https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/jtag-debugging/ Sidebar: this is one of the things that makes the ESP32-C3 family awesome - it's built into the chip as a second and third (JTAG + Console) USB endpoint so you don't need another dongle and another set of cables and hubs to wire up and keep connected, but that's going the wrong direction from The Beaten Path for you here. I'm just leaving a note that some ESP chips are more awesome in this regard than the chips you probably want to be working with. It looks like some ESP32-S3 boards have the debugging pod built in - that's the Kaluga reference. The Segger boards are a nice choice for a diversity of products, but they're not economy class. The Sipeed RVDebugger Plus or various FT232H boards will pair with OpenOCD and the various Bluepill solutions can speed up your transfers by offloading the bit-banging of the clocks and acks to the device instead of round-tripping over USB, but they're not a lot. At the low end of the shopping, you'll be on your own to work out cabling for the JTAG pins (Usually 4/5 pins) to your device under test. There are totally too many connectors and pinouts used for JTAG. If you're staying in the ESP32 space, searching Ali for [ esp prog jtag ] brings lots of options. It's up to you to figure out what'll work with whatever board you use. https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/jtag-debugging/ may help finding boards. Once you have this all worked out, you can pop into GDB, type 'bt' to get a backtrace to see the stack frames leading you to whatever faulted, inspect data and device registers, set breakpoints BEFORE the crash when you restart it, etc. If you're going to be doing any embedded work, this is an investment in tooling (hardware and mental) worth making.

…

On Thu, Jun 1, 2023 at 2:47 AM Bun-Bun2 ***@***.***> wrote: Yes, looking deeper I am finding lots of code with the expectation of 2 cores. Thanks for pushing me in the right direction. I've fixed up main.cpp and taskmgr.h (not elegantly mind you) to function with a single core. However now i've hit a StoreProhibited exception in ledbuffer.h. Progress! I have and see no real reason for me to use an ESP32-S2. I only got this by mistake from not paying attention to what I was ordering. However, pure curiosity has taken over to see if I can get it at least run the demo code. If not for any other reason than it's walking me through some of the code of the project. — Reply to this email directly, view it on GitHub <#291 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD35I4IFGHL25UNP5PSDXJBCKZANCNFSM6AAAAAAYRVEWMM> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/291/comments/6057490 @github.com>

[robertlipe]

Oh, wait. It looks like the S3 has a JTAG interface built into the SoC. https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-guides/jtag-debugging/configure-builtin-jtag.html https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-guides/jtag-debugging/index.html You "just" need to remap those pins to a USB connection on a computer and go from there. The adapter looks like it's built into the S3. So it's closer to a C3 than the S2, which has no JTAG at all. So I'm going to assign you the homework to handle the details here for whatever hardware combination you end up with. You CAN debug random crashes by adding debug prints until you find the spot just before your crash, but that can be a tough life. Hopefully at the very least, you can at least get a program counter and then run GNU addr2line to find what function it was in and work from there. Good luck!

…

On Thu, Jun 1, 2023 at 4:19 AM Robert Lipe ***@***.***> wrote: While you're ordering an ESP32-S3 (and more panels and more strips and more ....) you should probably add a JTAG probe to your order if you don't have one. That's another device where there's a bit of a startup distraction of learning about cables and OpenOCD and however it's connected in PIO and such, but it's SO worth it when it comes to debugging a crash or the ability to single step through an exception handler or even boot code if you need to do it. https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/jtag-debugging/ Sidebar: this is one of the things that makes the ESP32-C3 family awesome - it's built into the chip as a second and third (JTAG + Console) USB endpoint so you don't need another dongle and another set of cables and hubs to wire up and keep connected, but that's going the wrong direction from The Beaten Path for you here. I'm just leaving a note that some ESP chips are more awesome in this regard than the chips you probably want to be working with. It looks like some ESP32-S3 boards have the debugging pod built in - that's the Kaluga reference. The Segger boards are a nice choice for a diversity of products, but they're not economy class. The Sipeed RVDebugger Plus or various FT232H boards will pair with OpenOCD and the various Bluepill solutions can speed up your transfers by offloading the bit-banging of the clocks and acks to the device instead of round-tripping over USB, but they're not a lot. At the low end of the shopping, you'll be on your own to work out cabling for the JTAG pins (Usually 4/5 pins) to your device under test. There are totally too many connectors and pinouts used for JTAG. If you're staying in the ESP32 space, searching Ali for [ esp prog jtag ] brings lots of options. It's up to you to figure out what'll work with whatever board you use. https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/jtag-debugging/ may help finding boards. Once you have this all worked out, you can pop into GDB, type 'bt' to get a backtrace to see the stack frames leading you to whatever faulted, inspect data and device registers, set breakpoints BEFORE the crash when you restart it, etc. If you're going to be doing any embedded work, this is an investment in tooling (hardware and mental) worth making. On Thu, Jun 1, 2023 at 2:47 AM Bun-Bun2 ***@***.***> wrote: > Yes, looking deeper I am finding lots of code with the expectation of 2 > cores. Thanks for pushing me in the right direction. > > I've fixed up main.cpp and taskmgr.h (not elegantly mind you) to function > with a single core. However now i've hit a StoreProhibited exception in > ledbuffer.h. Progress! > > I have and see no real reason for me to use an ESP32-S2. I only got this > by mistake from not paying attention to what I was ordering. However, pure > curiosity has taken over to see if I can get it at least run the demo code. > If not for any other reason than it's walking me through some of the code > of the project. > > — > Reply to this email directly, view it on GitHub > <#291 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCSD35I4IFGHL25UNP5PSDXJBCKZANCNFSM6AAAAAAYRVEWMM> > . > You are receiving this because you commented.Message ID: > <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/291/comments/6057490 > @github.com> >