Anyone running 16MB flash ESP32-S3 boards? #375
Replies: 8 comments 6 replies
-
I’m on the Mac and have had the best luck with the factory drivers, at least so far, including on the S3.
Your board MIGHT have 16M of flash. Depends what chip I built that colored pre-production board with, but the “official” spec is WROVER-E-N8R8 which is 8M flash and 8M PSRAM.
We only currently use 4M of PSRAM because with this “style” of PSRAM (there are a few) you can only access 4M at a time. On the S3, I’ve been able to see all 8M, so maybe it has a larger addresss space or bigger bus.
I’m working a lot on the Feather S3 TFT board right now, which I think is 8M flash and 2M PSRAM, but they vary by part number. It all works though!
- Dave
… On Jul 24, 2023, at 10:55 PM, Robert Lipe ***@***.***> wrote:
I'm a microcontroller collector, but this was really my first exposure to ESP32. I'm looking for a hand with someone comfortable at the really low levels of these things. I'm hoping this rings bells for Mr. Dave based on his recent romp into the partition tables for the 8MB boards - maybe 16MB boards need hit with a similar hammer.
I have a few of these <https://wiki.luatos.com/chips/esp32s3/board.html> boards (select English in the left panel ... every time you click a link) That have an ESP32-S3 with "built-in 8MB psram, 16MB flash luxury configuration".
I learned the hard way that the MacOS serial driver doesn't play nicely with them, so you have to install the driver WCH ... who makes a serial controller that isn't even on this board as the S3 has an onboard USB bridge.
Running $ esptool.py -p /dev/cu.wchusbserial556E0082011 flash_id
Chip is ESP32-S3 (revision v0.1). (0.1 - for a CPU?!?! that's terrifying!) and
Detected flash size: 16MB
Flash type set in eFuse: quad (4 data lines)
Manufacturer: c8 which is: #define GIGADEVICE_ID 0xC8 /* GigaDevice */
So we really do have 16MB of flash and it's in the nice quad SPI configuration that'll gulp four bits per clock.
Most of the builds get barfed up by the board immediately. It doesn't want to associate with its little ESP32 or ESP32 siblings. It want only the top-shelf S3 code. So I tinkered with the LilyGo and HiTech S3 configurations, but decided that they had lots of extra configurations for LCDS and stuff that this bare board clearly doesn't have. I decided to focus on the 'ledstrip_feather' target and build up from there.
An erase_flash, followed by
pio run -vvv --upload-port /dev/cu.wchusbserial556E0082011 -e ledstrip_feather
Reveals that 4 sections are being sent to the board .... and that it's calling the tools with a "size = 4MB" option, which is questionable. I can't change it at this level because it's baked into the ELF and changing it here blows the checksum/signature. Still, we can see the actual upload is:
esptool.py"
--chip esp32s3
--port "/dev/cu.wchusbserial556E0082011"
--baud 1500000
--before default_reset --after hard_reset write_flash
-z --flash_mode dio --flash_freq 80m
--flash_size 4MB
0x0000 .pio/build/ledstrip_feather/bootloader.bin
0x8000 .pio/build/ledstrip_feather/partitions.bin
0xe000 ~/.platformio/packages/framework-arduinoespressif32/tools/partitions/boot_app0.bin
0x2d0000 ~/.platformio/packages/framework-arduinoespressif32/variants/adafruit_feather_esp32s3_tft/tinyuf2.bin
0x10000 .pio/build/ledstrip_feather/firmware.bin
It's a little suspicious that we don't have a spiffs/littlefs image being shipped over the wire, but here we are. The post-compression size gives us some confirmation on the contents of each ELF section:
Compressed 15040 bytes to 10331...
Wrote 15040 bytes (10331 compressed) at 0x00000000 in 0.3 seconds (effective 464.3 kbit/s)... That's a BIG bootloader
Wrote 3072 bytes (128 compressed) at 0x00008000 Partition tables compress well.
Wrote 8192 bytes (47 compressed) at 0x0000e000 I don't know what app0 was, but it's super sparse.
Wrote 185328 bytes (119268 compressed) at 0x002d0000 (That uf2 bootloader is big!)
Wrote 1516992 bytes (888109 compressed) at 0x00010000 (2:1 compression for RISC-code is typical)
Now I think I'm catching this at the beginning of the boot loop, but it's possible the merry-go-round has is already in motion by the time this log starts. My read is that it boots, becomes unhappy about the PSRAM thing (fatally unhappy or just grumbly?) and it whines about the absence of core dump partitions. I think I've seen that on Mesmerizer, too. It looks like core 1 takes an exception on a write (a store) and crashes. My assumption is that EXVCADDR is the equivalent of CR2 on a 386, so our fatal address was a whopping "4" - we failed on the boot code. My guess is that it's either an early stack use or, more likely, the relocation of code to RAM so it can run from faster space, which would match with the stack being in a memcpy(). I suspect that core0 is trooping on and runs a check upon the read ELF and I think it's the one at 0x10000 with 0x10000 .pio/build/ledstrip_feather/firmware.bin that has our actual .text and .data sections that we'd jump to once we're out of the bootloader, right? Notice that everything actually seems like a sensible crash, so I don't think our firmware is missing the top half of every word or something flagrantly pointing to flash read errors.
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x10 (DOWNLOAD(USB/UART0))
waiting for download
E (279) psram: PSRAM ID read error: 0x00ffffff
E (280) esp_core_dump_flash: No core dump partition found!
E (280) esp_core_dump_flash: No core dump partition found!
Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x420111b5 PS : 0x00060d30 A0 : 0x82011ab0 A1 : 0x3fcecf40
0x420111b5: __ulp at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/1/idf/crosstool-NG/.build/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdlib/mprec.c:659
A2 : 0x00000000 A3 : 0x00000000 A4 : 0x3fcecfa4 A5 : 0x00000000
A6 : 0x3fceeaf0 A7 : 0x0000005e A8 : 0x00000001 A9 : 0x3fcecf20
A10 : 0x00000000 A11 : 0x00000060 A12 : 0x00000046 A13 : 0x3fcf5e26
A14 : 0x3fcecee0 A15 : 0x00000008 SAR : 0x0000001e EXCCAUSE: 0x0000001d
EXCVADDR: 0x00000004 LBEG : 0x40056f08 LEND : 0x40056f12 LCOUNT : 0x00000000
0x40056f08: __memcpy_aux in ROM
0x40056f12: __memcpy_aux in ROM
Backtrace: 0x420111b2:0x3fcecf40 0x42011aad:0x3fcecf80 0x420322ee:0x3fced020
0x420111b2: __ulp at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/1/idf/crosstool-NG/.build/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdlib/mprec.c:659
0x42011aad: _svfiprintf_r at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/1/idf/crosstool-NG/.build/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdio/vfprintf.c:869
That stack makes some sense, too. vprintf calls mprec calls _ulp for floating point/decimal gunk. We're clearly running and doing computer stuff. It's not like its brain is totally scrambled. Sure, it's slamming into a wall, but we've not totally corrupted our opcode stream.
ELF file SHA256: 84db40078a0333bb
Warning: checksum mismatch between flashed and built applications. Checksum of built application is 43692d566e3730902ba6b4b943d041fc37abce4e6034ba584a83d851a3b3cee3
E (1881) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
Rebooting...
E (280) psram: PSRAM ID read error: 0x00ffffff
E (282) esp_core_dump_flash: No core dump partition found!
I saw in the boot code somewhere that ESP32-S3 images have a huge hash in addition to the CRC it's probably trying to check.
At some level, it's dumb to do $100 (LOL) debugging on a $20 board, but I figure that I'm maybe(?) more qualified to help work through this than the average Amazon/Ali shopper just pointing at a page and clicking "ESP32? Yes, please". (OK, those people are hopefully buying something like the M5Stick that's on the front page and known to be tested...)
I'd be perfectly happy if the board Just Worked as an (or even 4 or 2...)MB board for now. Better a working 2MB board than a crashing 16MB rock.
It's probably that bootloader.bin has grown by a LOT over an ESP32-S3-not (God, I hate their names...) These chips have a USB controller on board, so they can pretend to be a serial port -as we are - or they can boot up a tiny little USB stack and act like a USB drive that you can drag and drop (scp) bootable .uf2 images to for upgrades. So you need a USB stack, controller, modules, and filesystem code that the ESP32S (or ESP32) just doesn't need. (I think ESP32-s2, the single core mutant of the family, DOES have onboard USB.) 2D0000 + 185328 = an ending address of 2FD3F0. Have we walked past the end of RAM? Everything seems to be within the bounds of what was erased:
Flash will be erased from 0x00000000 to 0x00003fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x002d0000 to 0x002fdfff...
Flash will be erased from 0x00010000 to 0x00182fff...
'Hello world' from the IDF code correctly builds and runs. The "about me" stuff that it reports matches what's expected.
Downloading and running a Panlee configuration from https://plummerssoftwarellc.github.io/NightDriverStrip/ just kills the board dead. Not a single character gets transmitted once that code had been squirted into the board.
easyio and wled <https://wled.discourse.group/t/support-for-esp32-s2-logic-board/8106/3> don't support the S3, though both have it in the oven.
Am I onto the right track at all in thinking this is a flash memory size? I'd hope that extra memory would just hang off the end of address space if we didn't know about it and go unused, but maybe we have bits in an address overflowing or something.
Is ledstrip_feather a reasonable starting place?
Is there much documentation on memory maps and sector layouts and such? Even pointers within the code would be helpful it looks like we kind of magically appear in main() and I don't know my way around the pio build system to know where that '4mb' entry comes from.
Does anyone with a working S3 configuration have the chance to trade binaries with me? Are all the S3 boards "compatible enough" to at least boot and hopefully not get stuck spin-waiting an LCD control panner or touch input or something? (i.e can you boot a Lilygo T3 build on a HiLetGo or a Ledstrip_feather with each other's boards and binaries?)
This is the kind of thing that will PROBABLY be a three line change somewhere. Until then, it's like diagnosing a baby from just a cry or a car from just a "check engine" light.
—
Reply to this email directly, view it on GitHub <#375>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCFZUZ65PTYZSVYKIKSTXR5NTLANCNFSM6AAAAAA2WRIKTQ>.
You are receiving this because you are subscribed to this thread.
|
Beta Was this translation helpful? Give feedback.
-
FWIW, I went off the ranch and discovered https://github.com/BlueAndi/esp-rgb-led-matrix/tree/master It's not without challenges of its own, but the Lilygo T-Display3 code booted right away and a scope confirms WS2812 action on pin 6. It also does OTA, so it has bounce partitions. I'm still theorizing that the issue is in the partition tables and/or a memory map or load address somewhere. At least I now have a working binary for A/B testing. |
Beta Was this translation helpful? Give feedback.
-
Did you try duplicating and modifying the ledstrip_feather config? I run those all around the house, and they're S3. I don't know what a bounce partition is, but we do OTA as well as long as you have 8M flash. Or 4M on the S3, I think, |
Beta Was this translation helpful? Give feedback.
-
Maybe that's a Google term, but you know what it is - in another window,
you're suffering from it right now. :-)
In Android (and this ChromeOS and, I think, Magenta) A bounce partition is
an inactive copy of the system image. (C: ?) During an OTA, you can
scribble into the alternate partision, and boot knows to try loading it and
mark it successful if it did. If it didn't, it makes the working one active
and reboot back into that. This way if your flash dies while you're doing
an OTA, your phone will still boot. Probably.
I did not alter the ledstrip_feather at all. It was my hope that even if it
was smaller, it would just occupty a subset of the 8+16 S3. Maybe I should.
I saw the feather build had a hardcoded 4M in the stuff I showed you, but
I'm only now tracing it upstream. I see where board_build.partitions is
being set in platformio.ini, butI don't see where the total size is being
passed in. Actively working on that....
RJL
…On Tue, Jul 25, 2023 at 12:22 PM David W Plummer ***@***.***> wrote:
Did you try duplicating and modifying the ledstrip_feather config? I run
those all around the house, and they're S3.
I don't know what a bounce partition is, but we do OTA as well as long as
you have 8M flash. Or 4M on the S3, I think,
—
Reply to this email directly, view it on GitHub
<#375 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3ZMYX6XELHILAH2VHDXR76G3ANCNFSM6AAAAAA2WRIKTQ>
.
You are receiving this because you authored the thread.Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/375/comments/6542804
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
Hi, Mr. Mike!
Oh, yes. My PSRAM issues on S3 on the board I'm working on right now are
behind me. I solved it for my board by completely ignoring the "let's treat
S3 as an original ESP32 with some patches" approach and going to an
original description for the WROVER-1 module.
(W) (ConnectToWiFi)(C1) Connecting to Wifi SSID: "ElderOfTheInternet" -
ESP32 Free Memory: 228204, PSRAM:8377287, PSRAM Free: 8235607
(W)
(W) (ConnectToWiFi)(C1) Not yet connected to WiFi, waiting...
> Launching Network Thread. Mem: 228156, LargestBlk: 217076, PSRAM Free:
8235607/8377287, >> Launching ColorData Thread. Mem: 213992, LargestBlk:
204788, PSRAM Free: 8235607/8377287, (W) (NotifyJSONWriterThread)(C1) >>
Notifying JSON Writer Thread
I'm working on code right now that creates a new partition table (with
crash dump) and adds code to boot that automatically resizes partition
tables.
* Debug: Command received: help
(processRemoteDebugCmd)(C1) Unknown Command. Extended Commands:
(processRemoteDebugCmd)(C1) clock Refresh time from server
(processRemoteDebugCmd)(C1) stats Display buffers, memory, etc
(processRemoteDebugCmd)(C1) clearsettings Reset persisted user
settings
(processRemoteDebugCmd)(C1) uptime Show system uptime, reset
reason
(processRemoteDebugCmd)(C1)* cpuinfo Show information on CPU,
RAM, Flash*
(processRemoteDebugCmd)(C1) *partitions Show partition table*
(I) (WriteCurrentEffectIndexFile)(C0) Number of bytes written to file
/current.cfg: 1
c(I) (loop)(C1) WiFi: WL_CONNECTED, IP: 192.168.2.13, Mem: 181748,
LargestBlk: 167924, PSRAM Free: 8234371/8377079, LED FPS: 30 LED Bright:
100%, LED Watts: 11, CPU: 001%, 014%, FreeDraw: 0.019
puinfo
* Debug: Command received: cpuinfo
(processRemoteDebugCmd)(C1) CPU: ESP32-S3 Rev: 0 @ 240 Mhz
PSRAM: 8377079 bytes. Flash: 16777216 bytes 80000000 hz Speed: QIO
partitiona(I) (loop)(C1) WiFi: WL_CONNECTED, IP: 192.168.2.13, Mem: 181748,
LargestBlk: 167924, PSRAM Free: 8234371/8377079, LED FPS: 30 LED Bright:
100%, LED Watts: 11, CPU: 000%, 008%, FreeDraw: 0.019
^R
partitions
* Debug: Command received: partitions
(processRemoteDebugCmd)(C1)
Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x00b000, 0x002000,
otadata, data, data_ota, 0x00d000, 0x002000,
app0, app, ota_0, 0x010000, 0x190000,
app1, app, ota_1, 0x1a0000, 0x190000,
storage, data, spiffs, 0x330000, 0x0d0000,
First unallocated byte: 4194304 (0x400000)
Right now, I'm just treating it as a 4MB spiffs board until I can get it
resized and made into a littlefs partition.
This may all be too close to leading edge for NDL. Maybe I fork it and
maybe I argue it in, but I'm growing tired of that. I'm debugging
filesystem code in the other window right now...
I have two "pet" S3 boards in my life right now. The one I'm currently
working on it "just" a WROOM-1 plonked onto fiberglass with a regulator and
an inexplicable second UART. It's a the esp32-s3-devkitc-1-n16r8v and the
full package is the YD-ESP32-S3.
diff --git a/platformio.ini b/platformio.ini
index 0abce98..20c767e 100644
--- a/platformio.ini
+++ b/platformio.ini
@@ -200,13 +200,26 @@ board_build.partitions =
config/partitions_custom_8M.csv
board_upload.flash_size = 8MB
[dev_lilygo-tdisplay-s3]
-extends = dev_esp32-s3
+extends = dev_esp32-s3
build_flags = -DLILYGOTDISPLAYS3=1
-DPIN_SDA=21
-DTOGGLE_BUTTON_1=0
-DTOGGLE_BUTTON_2=14
${dev_esp32-s3.build_flags}
+; Bare development module with Uses ESP32-S3-WROOM-1 module as N8R2 or
N16R8
+; Specifically https://www.aliexpress.us/item/3256805600763040.html
+; Picture shows "YD-ESP32-S3", but actual silk screen sayd "YD-ESP32-23"
+; Probably a clone of https://www.aliexpress.us/item/3256805600763040.html
+; This is hard for us to get right when Platformio itself screws this up.
+; ESP32-WROOM-1 will use QIO Flash and PSRAM. WROOM-2 will use OPI.
+[dev_yd-esp32-s3]
+extends = base
+monitor_speed = 115200
+upload_speed = 921600 ; The 'emulated' UART won't do 1.5MBPS
+board = esp32-s3-devkitc-1-n16r8v
+build_flags = ${dev_esp32-s3.build_flags}
+
; ===================
; Capability sections
;
@@ -337,6 +350,13 @@ build_flags = -DDEMO=1
-DENABLE_WIFI=1
-DUSE_SCREEN=0
${dev_lilygo-tdisplay-s3.build_flags}
+; YD-ESP32-S3
+[env:yd-esp32-s3-demo]
+extends = dev_yd-esp32-s3
+build_flags = -D DEMO=1
+ -D ENABLE_WIFI=1
+ -D ENABLE_WEBSERVER=1 ; Turn on the internal webserver
+ ${dev_yd-esp32-s3.build_flags}
;=============
Also from my notes:
Download
https://github.com/handledexception/platform-espressif32/blob/esp32-s3-devkitc-1-n16r8v/boards/esp32-s3-devkitc-1-n16r8v.json
mv ~/Downloads/esp32-s3-devkitc-1-n16r8v.json
~/.platformio/platforms/espressif32/boards/esp32-s3-devkitc-1-n16r8v.json
My second bunch of boards (which isn't in my reach ATM) is the
LUATOS-ESP32-S3. http://luatos.com/t/esp32s3. I know I've had them running
with full flash and PSRAM glory, but I haven't done the line-by-line
analysis of the board files against the data sheets since they're using
"raw" chips and not the canned modules. I was trying to focus on the more
mainstream cases first.
I probably have some more "mutt" boards around (the $$$ one I'd like to add
support for is ESP32-S3-Box, which I bought before Mesmerizer crossed my
desk) but right now Im focusing on making the <$5 boards super awesome and
I'll loop back to the $50 boards later.
Now, with all that Beast Mode ESP32 machismo behind me, I have to say that
if your'e running some reasonable number of LEDs on a single strip or two
and have been reasonable about the configuration you've enabled, that the
USE_WS281X case *should be* pretty happy even without PSRAM. I think the
USE_HUB75 case will burst into flames, but making that burst into flames
more dramatically and closer to the time of decision is on my short list of
improvements.
So that's where I am and sort of where I expect the bar to be - worth
fixing PSRAM for HUB75; less so for WS_281x strips - more so if you're
shipping video streams to the device (I think Dave does this a LOT) via
terrible wifi and less so if your effects are all local, as mine tend to be
- so how can I best help you? Are you suffering pain from PSRAM not working
where you need that to work for your exact combination (I may be able to
hep) or are you just asking the state of the union?
I also realize my patch is getting huge. Adding new commands to the onboard
debugger (as shown above) is a cool trick, but maybe busting that all into
a table should have been a second patch. If I thought anyone else was this
deep into the code and risking a merge conflict, I'd probably be more
worried about it. And if it becomes back-breaking(er) to argue it in, I'll
just run my own tree that's tuned a bit better for newer, more raw boards.
I'll readily admit that I added the "cpuinfo" and "partitions" commands to
debug problems that I, probaly uniquely, am having at this moment and they
may not be useful in the general purpose tree. I've also learned a LOT
about the mapping of chips/modules/boards/features in the S3 speace and all
kinds of nuances like even the oio boards shift down to dio mode during
code upload. Debugging how and when they fail can be super frustrating. To
help with this, I plan to add benchmarks/reliability tests to help validate
that things like QIO vs. OIO really are dialed in and reliable before we
use them, but I'm not there yet.
I'm in S3 pretty deep right now. How can I help you, Mike?
RJL
…On Thu, Nov 9, 2023 at 1:33 AM mikejohnau ***@***.***> wrote:
Hi Robert,
I've just taken possession of a couple of ESP32-S3 boards with 16MB flash
and 8MB PSRAM.
Now I can fire them up with a version of the LedStrip build and they work,
but only by deleting all reference to PSRAM in the build flags in
platformio.ini.
Did you ever manage to get PSRAM sorted on your S3? I cant see where PSRAM
is set up for other S3's other than in the build flags.
—
Reply to this email directly, view it on GitHub
<#375 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD35TCLNH3SSAVQZ4MVLYDSBN7AVCNFSM6AAAAAA2WRIKTSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKMJZGA3DQ>
.
You are receiving this because you authored the thread.Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/375/comments/7519068
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
CPU: 80C88. LOL.
Read on if you want to learn to fish
<https://en.wiktionary.org/wiki/give_a_man_a_fish_and_you_feed_him_for_a_day;_teach_a_man_to_fish_and_you_feed_him_for_a_lifetime>.
Search this message for ****** if you just want a fish sandwich. If you
then come back and ask something answered here, expect to be mocked. :-)
That board looks like it's effectively a clone of the same thing that the
board I'm currently working on. You can even see hints of that in the silk
screen on the back where it talks about the DevKitC-1. If you look at the
electronics on it, it's little more than a voltage regulator (probably an
AMS1117-3.3 family member), a WS-2812B onboard that's attached to some
mystery GPIO pin (mine requires a tiny solder dot to use that; I'm happy
not installing that, thus ignoring that LED for now) and two FETs to handle
the switching from the buttons to drive GPIO0 and, I think, 3 for the
bootstrapping pins. There are two 5.1K resistors on each of the USB-C lines
to stop it from being shamed on lists like
https://www.robertlipe.com/usb-c-power-issues-with-development-boards/ and
there's some random UART to feed the second USB port - that'll be the
'UART' port. Right now, my builds are configured to use the 'USB' port
which goes straight to the ESP32. The upside is that it goes straight to
the ESP32. The downside is that this goes straight to the ESP32 which means
that if you reset the chip, for example, the connection to your computer
gets reset which means you lose your debugger and serial connection. I'm
using that port because it allows me to use the debugger (poorly) from the
same cable because it also offers a second USB interface for the JTAG
services.
Riding so closely on my coattails means that you can probably use my
configuration (which I have yet to submit) almost exactly.
Again, intentionally or otherwise, you actually hit upon the reason you see
the difference; you just havent realized it because it doesn't make any
sense. The environment (spectrum, demo, panlee, umbrella, cheiftain, etc)
doesn't ONLY pick the display pattern that gets used, it ALSO picks the SOC
configuration (ESP32, ESP32-S3, each with or without PSRAM, etc.) that gets
used. I kind of cherry picked the examples, but it makes more sense when
you notice the targets like "m5demo", "m5plusdemo", "heltecdemo",
"heltecv3demo", "heltecv2demo" and so on. You have to really understand the
platformio inheritance model (I wrote a lengthy description of it a few
weeks ago) to notice that mesmerizer environment (search for
'env:mesmerizer' in platformio.ini) uses the build flags from
${mesmerizer_config.build_flags} so when you find mesmerizer_config (search
for that now) you'll find build_flags including:
[mesmerizer_config]
build_flags = -DMESMERIZER=1
-DUSE_HUB75=1
${psram_flags.build_flags}
${remote_flags.build_flags}
That psram_flags.build_flags inherits from THAT configuration (search now
for [psram_flags]) which contains: ; Build flags for use of PSRAM
[psram_flags]
build_flags = -DUSE_PSRAM=1
-DBOARD_HAS_PSRAM=1
-mfix-esp32-psram-cache-issue
taa daa! Theres the needed BOARD_HAS_PSRAM flag that tells the OS to use it
and the USE_PSRAM flag which is internal to NDL and hints on things like
buffer sizes to use.
However, like a sock that's too small, it fits enough to get the code
booted and seeing PSRAM, but it's not really the right size as it's still
deriving from [dev_esp32] which sets 'board esp32dev' and not
[dev_esp32-s3] which uses 'board esp32-s3-devkitc-1' ... and inexplicably
sets some other stuff that's not really right, but is certainly not
actually right/optimal for YOUR board. For that, you have to create a new
board config - which I just happened to do and provided in the message I
sent before bedtime - which I named 'yd-esp32-s3-demo' that sets all those
flags, but actually chooses the correct CPU model for that board and sets
some other stuff that's needed/appropriate for our boards.
Depending on the success of you following, I might name it something more
generic than "yd-..." as https://github.com/vcc-gnd/YD-ESP32-S3 is
probably more accurately a clone of the devkitc form factor, but with an
S3. (You can tell I'm still struggling a bit with the names. The BOARD is
different than the MODULE, but we like to call them the same thing.)
Depends on how far the cheap boards drift from
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/hw-reference/esp32s3/user-guide-devkitc-1.html
- it looks like even on Espressif's own board, the WS2812 is on pin 38 or
pin 48 depending on when it was made. On my board, it's on 48, but only
once you monkeypatch a bridge.
vcc-gnd/YD-ESP32-S3#1 (That's both a bug and a
feature - it's underdocumented, but it means that GPIO48 is available on
PIN29 for other use...your board may have a similar feeeeeeeature.)
You could probably almost get a demo config workign with the stock tree by
using something like lilygo-tdisplay-s3-demo, but then you get into trouble
because the code thinks you have a screen and buttons attached in specific
places and other distractions.
So in fantasy land, our names would be tuples that named the board AND the
display used, which we sometimes have (like in the case
of lilygo-tdisplay-s3-demo) but we really aren't prepared for the explosive
combination of {lilygo, heltec, heltecv2, heltecv3, m5, m5plus, m5plusc,
etc) * (demo, spectrum, laserline, chieftain, umbrella, .etc) which would
probably blow up to a few hundred (!) combinations.
There has to be a better way...I'm struggling to find that scheme for a
future monster renaming, but for now we're just adding new targets.
This is why I added my new configuratino above to be very specific (board +
effect) and didn't split the configuration between platformio.ini and
include/globals.h
Oh. This configuration also leaves 75% of your flash memory unused, but
that's OK because we're currently using, like 18 bytes or something. That
becomes more apparent when you run my (also unsubmitted) 'partitions'
command in the debugger:
* Debug: Command received: partitions
(processRemoteDebugCmd)(C1)
Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x00b000, 0x002000,
otadata, data, data_ota, 0x00d000, 0x002000,
app0, app, ota_0, 0x010000, 0x190000,
app1, app, ota_1, 0x1a0000, 0x190000,
storage, data, spiffs, 0x330000, 0x0d0000,
First unallocated byte: 4194304 (0x400000)
My current work is to provide an appropriate tiny configuration that
includes no user partition AT ALL and then resizes it on startup to be
appropriate so we don't also have a triplet of board + flash size + display
- nobody wants a third axis on that matrix I described.
Oh. and just to be stubborn, I'm going to change the filesystem type from
the deprecated SPIFFS to LITTLEFS - there's no reason for these boards to
start life on a deprecated filesystem. So that adds to the weight I'm
pulling in supporting all this right.
There's a lot going on to do this well. We also need an official target
that supports all the displays (at the very least, a matrix configuration)
but it's nto totally clear if we can or should call that a 'mesmerizer'
depending on trademarks or market confusion with Dave's upcoming board.
I'll probably add a light memory/flash test because SPI flash and SPI RAM
can be a bit fragile and I'd rather it fail during startup (or a debugger
command) than later when we're decoding cover art or dragging and dropping
your meme collection or something. Oh, yeah, I -also-- have work in the
oven extending reading and writing files from the webserver to
storage...and get a directory listing. Misconfigured PSRAM will sometimes
crash the device when used, so it's worth trying to get right.
For bonus esp32-s3 fun, you may find the following inspirational until I
can get something like this more productized:
➜ nightdriverstrip git:(yd32) ✗ cat tools/openocd_start
~/.espressif/tools/openocd-esp32/v0.12.0-esp32-20230419/openocd-esp32/bin/openocd
-f
~/.espressif/tools/openocd-esp32/v0.12.0-esp32-20230419/openocd-esp32/share/openocd/scripts/board/esp32s3-builtin.cfg
➜ nightdriverstrip git:(yd32) ✗ cat tools/openocd_start
~/.espressif/tools/openocd-esp32/v0.12.0-esp32-20230419/openocd-esp32/bin/openocd
-f
~/.espressif/tools/openocd-esp32/v0.12.0-esp32-20230419/openocd-esp32/share/openocd/scripts/board/esp32s3-builtin.cfg
➜ nightdriverstrip git:(yd32) ✗ cat .gdbinit
target remote localhost:3333
➜ nightdriverstrip git:(yd32) ✗ cat tools/fast_load
# Notes: 0x10000 is start of partition 0
# filename is hardcoded.
#
OPENOCD=~/.espressif/tools/openocd-esp32/v0.12.0-esp32-20230419/openocd-esp32/share/openocd
BIN=~/.platformio//packages/tool-openocd-esp32/bin/openocd
# ${BIN} -f ${OPENOCD}/scripts/board/esp32s3-builtin.cfg -c "program_esp
.pio/build/yd-esp32-s3-demo/firmware.bin 0x10000 verify reset exit"
${BIN} -f ${OPENOCD}/scripts/board/esp32s3-builtin.cfg -c "program_esp
.pio/build/yd-esp32-s3-demo/firmware.bin 0x10000 reset exit"
You might also find that kind of thing to be horrifying. That's OK, too. I
certainly know that hardcoding all those pathnames is terrible. This is
just the view from inside the sausage factory while the sausage is being
made. :-) The program loader, for example, is quite fast compared to the
serial loader because it can use the USB bulk pipes for the JTAG transfer
instead of the interrupt pipes used by the serial mode. The bulk of the
time is erasing, but it plays out like...
Info : [esp32s3.cpu1] requesting target halt and executing a soft reset
Info : [esp32s3.cpu0] Core was reset.
Info : [esp32s3.cpu1] Debug controller was reset.
Info : [esp32s3.cpu1] Core was reset.
shutdown command invoked
tools/fast_load 1.99s user 1.15s system 16% cpu 19.046 total
The erase takes four seconds of that 19. The nice thing is that the program
can be WAY bigger and it doesn't really take linearly more time. It's
certainly dwarfed by platformio's dumb insistence on running a trainload of
python to parse source code for dependencies instead of just letting gcc
-MMD do it.
Soooo. what's the TL;DR of all that? (And please DO actually read this
stuff. I ramble, but I'm educational as hell.)
******
Copy those two hunks above into your platformio and you'll get a new
environment target named
esp32-s3-devkitc-1-n16r8v
You can probably build that from the GUI or you can script it in your
favorite way (see my "Zen" post in show and tell)
pio run --target upload -e yd-esp32-s3-demo
******
It currently underachieves on the flash and I won't guarantee that it'll
OTA update to future versions cleanly (I'll almost guarantee it won't...)
but that SHOULD get you an actual ESP32-S3 today binary that screams on
your board running the DEMO environment. Change DEMO in my little hunk to
whatever strip configuration you like. $PLATFORMIO_UPLOAD_PORT is, of
course, set to your serial port. On my (MacOS) system, I run ioreg -l to
find it.
I know the board will easily do HUB75. I hacked up (and gave away) a board
or two using that, but all my focus right now is adding S3 support right
(and helping with the flash being 2, 4, 8, 16 or - coming soon - 32 MB)
into the project without making 6x as many builds. I'm sure Rutger doesn't
want to provide bins for (esp32/esp32s3/esph4) * (no flash/2/4/8/16/32 MB)
PSRAM (None/QIO/OIO) * (demo/panlee/mesmerizer/spectrum/....)
No, I don't have a targeted completion date, but this IS one of my active
hobby projects right now, so it's not ideas on a shelf; I'm working on it.
In related news, I halfway expected Espressif to announce dual-core
RISC-V's this week at the annual RISC-V convention this week. ESP32-P4
<https://www.espressif.com/en/news/ESP32-P4> is just a pair of stupid
C906's without WiFi (pretty important for an IoT chip company....) isn't
exactly interesting in our market. They're due for something better.
…On Thu, Nov 9, 2023 at 4:21 AM mikejohnau ***@***.***> wrote:
One thing that I have noticed is that even with the original esp32's my
mesmeriser build uses the PSRAM on the Wrover but the ledstrip and spectrum
builds don't.
So it appears that not of all of the environments are using PSRAM if
available.
Off topic I know, but I was just checking with my other builds to see
which were successfully using PSRAM and on which module..
—
Reply to this email directly, view it on GitHub
<#375 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD36ALY5R5GDMI224W4TYDSVCRAVCNFSM6AAAAAA2WRIKTSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKMRQG42DI>
.
You are receiving this because you authored the thread.Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/375/comments/7520744
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
-mfix-esp32-psram-cache-issue
Is a hindrance on S3. S3 never had the bug that this is working around.
-DBOARD_HAS_PSRAM is probably the one you were missing.
Extending base gets you several other flags that are distractions.
Certainly the unity build flags are nonsensical for any ESP32 build. If
you're extending the right model, you won't have to set cpu_speed and mcu
name and such. But whatever, you have something that works for you, so go
with it.
I've spent hours stitching this stuff together and carefully matching them
up to avoide this kind of thing because we currently have it All Over
platform.ini on these "fringe" boards. I'll keep working get official ones
submitted once I'm done tuning them. For example, you've probably not
noticed that only part of your flash is working. I'm working on a solution
for that, too.
Glad you're on the move now. That's two for two today!
…On Thu, Nov 9, 2023 at 7:34 PM mikejohnau ***@***.***> wrote:
Device section:
[dev_esp32-s3]
extends = base
board = lolin_s3
board_build.mcu = esp32s3
board_build.f_cpu = 240000000L
monitor_speed = 115200
upload_speed = 1000000
Env section:
[env:ledstrip_s3]
extends = dev_esp32-s3
build_flags = -DLEDSTRIP=1
-DUSER_SETUP_LOADED
-DBOARD_HAS_PSRAM=1
-mfix-esp32-psram-cache-issue
-Os
${unity_double_flags.build_flags}
${dev_esp32-s3.build_flags}
—
Reply to this email directly, view it on GitHub
<#375 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD33XBRTUKYJJXVTNIFLYDWADPAVCNFSM6AAAAAA2WRIKTSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKMRYGY2DO>
.
You are receiving this because you authored the thread.Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/375/comments/7528647
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
ESP32-S3-DevKit N16R8. It was my assumption it would mostly work out of
the box since there are configurations in platformio.ini for the
esp32-s3-devkitc-1 board. But, I would not be here if that were the case.
I run buckets of those boards and have more on the way. I have support for
them in the oven. Rutger and I have loosely kicked around the concept of
how to support modules like these that are kind of 'raw modules' and not
really tied to a configuration (is it a mesmerizer? Is it a spectrum? What
are the pins connected to? Is there a mic/remote/screen?) and haven't
really come up with a plan, but we've not really confronted it head-on
because so far, that crowd has been kind of self-sufficient. It's an area
in need of intense documentation as it's kind of a raw component rather
than an end-to-end configuration of SOC + Flash/RAM + Effects. . I have
some in progress.
I've named mine after the extremely specific clone of this board, but am
increasingly convinced it's "right" to name it after Espressif device it's
cloning. More on that in a moment.
I am at the system crashing phase of figuring this out and hope I can
follow the above suggestions to get it working.
Last week or so, I added a one line change that took me for-ev-er to find
that would affect this board and certain configurations.
But first, it took me a couple of hours to get my Mac to even program the
board.
I'm also on Team Mac. You're in luck.
The board has two USBC ports. One is labeled USB and the other COM. You
would think one or the other would work. Nope.
They both work ... in different ways.
One is the USB port on the SOC itself. If we were to attach a mouse,
external flash drive (!), keyboard, or anything else that wanted the device
itself to be the controller, this is your port.
This port is awesome because it's on the SOC itself and lets you run GDB,
power the devicee, and do serial console all at once.
This port is terrible because its on the SOC itself and thus resets when
the chip resets. So your debugger connection, for example, can't
persisit across a reboot.
The other port is awesome because it's a dedicated UART and is faster. It
can do "uart things" while the SOC resets.
This port is terrible because it uses a device that's subtly incompatible
with MacOS. You'll get a /dev/cu.usbserial54E20526551 that works just well
enough to pull you in, but is unreliable enough that even upload doesn't
work. You have to install a driver from Win Chip Head from a site that's
extremely Chinese and click the "yes, I trust this driver with my life"
during installation. After reboot (first sign that it wasn't really done by
Mac People) you'll additionally get a subtly different port name, only it
actually works. From my logs:
export PLATFORMIO_UPLOAD_PORT=/dev/cu.wchusbserial54E20526551
This port requires extra #defines upon build to catch most of the serial
debug console stuff. I've chosen to let the default go to the other.
Upon boot, most stuff goes to both ports for about the first second, then
only the native /dev/usbserial gets the debugFoo chatter. Combined with the
other thing, it "works" just well enough to be a time sink, unless you turn
on the -Ddefine for it, to fool you. In my builds, I'm choosing to ignore
this port and focus on the port provided by the SOC.
My upload script currently looks like hell, but encapsulates all the above:
➜ nightdriverstrip git:(main) ✗ cat go-yd
# This is for the YD-ESP32-23 (S3) - use the "serial" serial port
if [ ! -c $PLATFORMIO_UPLOAD_PORT ];
then
# The YD-board will be /dev/cu.usbserial1101 or cu.usbmodem1101 at random
# The 1101 in this eaample is physical port configuration (front of MBP)
export PLATFORMIO_UPLOAD_PORT=$(ioreg -l | awk -F\"
'/IOCalloutDevice.*usb(serial|modem)/ {P=$4}; END{print P}')
# export PLATFORMIO_UPLOAD_PORT=$(ioreg -l | awk -F\"
'/IOCalloutDevice.*usbserial/ {P=$4}; END{print P}')
fi
set -e
# E=esp32-s3-devkitc-1-n16r8v
E=yd-esp32-s3-demo
#~/.platformio/penv/bin/pio run -e $E
~/.platformio/penv/bin/pio run --target upload -e $E
#~/.platformio/penv/bin/pio run --target buildfs -e $E
while :
do
(stty 115200; cat -u ) < $PLATFORMIO_UPLOAD_PORT || exit 1
done
It took connecting a USB cable to both ports and connecting to two USBC
ports on my MacBook Air. Not surprising since I can't connect a regular
USBC-USBC cable to my heltec board. I have to go USBC/MUSBA->FUSBA/USBC
cable combo for that.
I'm able to develop and debug reliably on the port labeled "USB" (the SOC)
and largely ignore the "COM" port (the UART). I do keep the WCH driver
installed on my dev system and, as hinted by the uncertainty of it. I keep
extra stuff in the files so that I can copy-paste them out and run them
individually.
I've not cleaned this up and tried to "productize" it all yet. I intend to
do so. You're welcome to ride along on my coattails, but mine are
development platforms and not really products. As such, a few of my
configuration choices aren't suitable.
For example, I'm NOT submitting 16MB flash configurations. My current (well
"current" == on holiday travel and in bed, feeling bad...) project is
working on figuring out flash memory size and resizing it on the fly. Oh,
and replacing SPIFFS with LIttleFS. So MY configuration uses a special
partition table, for example. If I were you, I'd just take the 8MB
filesystem partition table and ignore the rest (nothing really uses it yet
anyway - that's another another project I'm working on) But here's my
project.ini that goes with that script above.
+; Bare development module with Uses ESP32-S3-WROOM-1 module as N8R2 or
N16R8
+; Specifically https://www.aliexpress.us/item/3256805600763040.html
+; Picture shows "YD-ESP32-S3", but actual silk screen sayd "YD-ESP32-23"
+; Probably a clone of https://www.aliexpress.us/item/3256805600763040.html
+; This is hard for us to get right when Platformio itself screws this up.
+; ESP32-WROOM-1 will use QIO Flash and PSRAM. WROOM-2 will use OPI.
+[dev_yd-esp32-s3]
+extends = base
+monitor_speed = 115200
+upload_speed = 921600 ; The 'emulated' UART won't do 1.5MBPS
+board = esp32-s3-devkitc-1-n16r8v
+debug_init_break = tbreak setup
+build_flags = ${dev_esp32-s3.build_flags}
+board_build.partitions = config/partitions_custom_max.csv
I guess part of the adventure of working with this project is figuring out
the weird combos to get it working.
I'm sorry you suffered on that. I've been sitting on it because it's tied
into several larger projects of mine.
Now back to figure out how to stop system crashes. It might actually be a
bug in some of my custom code.
The following scripts may also be inspirational. Clearly, they're for my
own use and will need tweaking for your case, but it's enough to let you
get a debugger going:
➜ nightdriverstrip git:(main) ✗ cat tools/gdb_start
~/.espressif/tools/xtensa-esp-elf-gdb/12.1_20221002/xtensa-esp-elf-gdb/bin/xtensa-esp32s3-elf-gdb
-f .pio/build/yd-esp32-s3-demo/firmware.elf
➜ nightdriverstrip git:(main) ✗ cat tools/openocd_start
~/.espressif/tools/openocd-esp32/v0.12.0-esp32-20230419/openocd-esp32/bin/openocd
-f
~/.espressif/tools/openocd-esp32/v0.12.0-esp32-20230419/openocd-esp32/share/openocd/scripts/board/esp32s3-builtin.cfg
➜ nightdriverstrip git:(main) ✗ cat .gdbinit
target extended-remote localhost:3333
Gotta run, but that should be enough to get you going - or going in a
different direction.
RJL
|
Beta Was this translation helpful? Give feedback.
-
I'm a microcontroller collector, but this was really my first exposure to ESP32. I'm looking for a hand with someone comfortable at the really low levels of these things. I'm hoping this rings bells for Mr. Dave based on his recent romp into the partition tables for the 8MB boards - maybe 16MB boards need hit with a similar hammer.
I have a few of these boards (select English in the left panel ... every time you click a link) That have an ESP32-S3 with "built-in 8MB psram, 16MB flash luxury configuration".
I learned the hard way that the MacOS serial driver doesn't play nicely with them, so you have to install the driver WCH ... who makes a serial controller that isn't even on this board as the S3 has an onboard USB bridge.
Running $ esptool.py -p /dev/cu.wchusbserial556E0082011 flash_id
Chip is ESP32-S3 (revision v0.1). (0.1 - for a CPU?!?! that's terrifying!) and
Detected flash size: 16MB
Flash type set in eFuse: quad (4 data lines)
Manufacturer: c8 which is: #define GIGADEVICE_ID 0xC8 /* GigaDevice */
So we really do have 16MB of flash and it's in the nice quad SPI configuration that'll gulp four bits per clock.
Most of the builds get barfed up by the board immediately. It doesn't want to associate with its little ESP32 or ESP32 siblings. It want only the top-shelf S3 code. So I tinkered with the LilyGo and HiTech S3 configurations, but decided that they had lots of extra configurations for LCDS and stuff that this bare board clearly doesn't have. I decided to focus on the 'ledstrip_feather' target and build up from there.
An erase_flash, followed by
pio run -vvv --upload-port /dev/cu.wchusbserial556E0082011 -e ledstrip_feather
Reveals that 4 sections are being sent to the board .... and that it's calling the tools with a "size = 4MB" option, which is questionable. I can't change it at this level because it's baked into the ELF and changing it here blows the checksum/signature. Still, we can see the actual upload is:
esptool.py"
--chip esp32s3
--port "/dev/cu.wchusbserial556E0082011"
--baud 1500000
--before default_reset --after hard_reset write_flash
-z --flash_mode dio --flash_freq 80m
--flash_size 4MB
0x0000 .pio/build/ledstrip_feather/bootloader.bin
0x8000 .pio/build/ledstrip_feather/partitions.bin
0xe000 ~/.platformio/packages/framework-arduinoespressif32/tools/partitions/boot_app0.bin
0x2d0000 ~/.platformio/packages/framework-arduinoespressif32/variants/adafruit_feather_esp32s3_tft/tinyuf2.bin
0x10000 .pio/build/ledstrip_feather/firmware.bin
It's a little suspicious that we don't have a spiffs/littlefs image being shipped over the wire, but here we are. The post-compression size gives us some confirmation on the contents of each ELF section:
Compressed 15040 bytes to 10331...
Wrote 15040 bytes (10331 compressed) at 0x00000000 in 0.3 seconds (effective 464.3 kbit/s)... That's a BIG bootloader
Wrote 3072 bytes (128 compressed) at 0x00008000 Partition tables compress well.
Wrote 8192 bytes (47 compressed) at 0x0000e000 I don't know what app0 was, but it's super sparse.
Wrote 185328 bytes (119268 compressed) at 0x002d0000 (That uf2 bootloader is big!)
Wrote 1516992 bytes (888109 compressed) at 0x00010000 (2:1 compression for RISC-code is typical)
Now I think I'm catching this at the beginning of the boot loop, but it's possible the merry-go-round has is already in motion by the time this log starts. My read is that it boots, becomes unhappy about the PSRAM thing (fatally unhappy or just grumbly?) and it whines about the absence of core dump partitions. I think I've seen that on Mesmerizer, too. It looks like core 1 takes an exception on a write (a store) and crashes. My assumption is that EXVCADDR is the equivalent of CR2 on a 386, so our fatal address was a whopping "4" - we failed on the boot code. My guess is that it's either an early stack use or, more likely, the relocation of code to RAM so it can run from faster space, which would match with the stack being in a memcpy(). I suspect that core0 is trooping on and runs a check upon the read ELF and I think it's the one at 0x10000 with 0x10000 .pio/build/ledstrip_feather/firmware.bin that has our actual .text and .data sections that we'd jump to once we're out of the bootloader, right? Notice that everything actually seems like a sensible crash, so I don't think our firmware is missing the top half of every word or something flagrantly pointing to flash read errors.
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x10 (DOWNLOAD(USB/UART0))
waiting for download
E (279) psram: PSRAM ID read error: 0x00ffffff
E (280) esp_core_dump_flash: No core dump partition found!
E (280) esp_core_dump_flash: No core dump partition found!
Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x420111b5 PS : 0x00060d30 A0 : 0x82011ab0 A1 : 0x3fcecf40
0x420111b5: __ulp at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/1/idf/crosstool-NG/.build/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdlib/mprec.c:659
A2 : 0x00000000 A3 : 0x00000000 A4 : 0x3fcecfa4 A5 : 0x00000000
A6 : 0x3fceeaf0 A7 : 0x0000005e A8 : 0x00000001 A9 : 0x3fcecf20
A10 : 0x00000000 A11 : 0x00000060 A12 : 0x00000046 A13 : 0x3fcf5e26
A14 : 0x3fcecee0 A15 : 0x00000008 SAR : 0x0000001e EXCCAUSE: 0x0000001d
EXCVADDR: 0x00000004 LBEG : 0x40056f08 LEND : 0x40056f12 LCOUNT : 0x00000000
0x40056f08: __memcpy_aux in ROM
0x40056f12: __memcpy_aux in ROM
Backtrace: 0x420111b2:0x3fcecf40 0x42011aad:0x3fcecf80 0x420322ee:0x3fced020
0x420111b2: __ulp at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/1/idf/crosstool-NG/.build/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdlib/mprec.c:659
0x42011aad: _svfiprintf_r at /Users/brnomac003/.gitlab-runner/builds/qR2TxTby/1/idf/crosstool-NG/.build/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdio/vfprintf.c:869
That stack makes some sense, too. vprintf calls mprec calls _ulp for floating point/decimal gunk. We're clearly running and doing computer stuff. It's not like its brain is totally scrambled. Sure, it's slamming into a wall, but we've not totally corrupted our opcode stream.
ELF file SHA256: 84db40078a0333bb
Warning: checksum mismatch between flashed and built applications. Checksum of built application is 43692d566e3730902ba6b4b943d041fc37abce4e6034ba584a83d851a3b3cee3
E (1881) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
Rebooting...
E (280) psram: PSRAM ID read error: 0x00ffffff
E (282) esp_core_dump_flash: No core dump partition found!
I saw in the boot code somewhere that ESP32-S3 images have a huge hash in addition to the CRC it's probably trying to check.
At some level, it's dumb to do $100 (LOL) debugging on a $20 board, but I figure that I'm maybe(?) more qualified to help work through this than the average Amazon/Ali shopper just pointing at a page and clicking "ESP32? Yes, please". (OK, those people are hopefully buying something like the M5Stick that's on the front page and known to be tested...)
I'd be perfectly happy if the board Just Worked as an (or even 4 or 2...)MB board for now. Better a working 2MB board than a crashing 16MB rock.
It's probably that bootloader.bin has grown by a LOT over an ESP32-S3-not (God, I hate their names...) These chips have a USB controller on board, so they can pretend to be a serial port -as we are - or they can boot up a tiny little USB stack and act like a USB drive that you can drag and drop (scp) bootable .uf2 images to for upgrades. So you need a USB stack, controller, modules, and filesystem code that the ESP32S (or ESP32) just doesn't need. (I think ESP32-s2, the single core mutant of the family, DOES have onboard USB.) 2D0000 + 185328 = an ending address of 2FD3F0. Have we walked past the end of RAM? Everything seems to be within the bounds of what was erased:
Flash will be erased from 0x00000000 to 0x00003fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x002d0000 to 0x002fdfff...
Flash will be erased from 0x00010000 to 0x00182fff...
'Hello world' from the IDF code correctly builds and runs. The "about me" stuff that it reports matches what's expected.
Downloading and running a Panlee configuration from https://plummerssoftwarellc.github.io/NightDriverStrip/ just kills the board dead. Not a single character gets transmitted once that code had been squirted into the board.
easyio and wled don't support the S3, though both have it in the oven.
Am I onto the right track at all in thinking this is a flash memory size? I'd hope that extra memory would just hang off the end of address space if we didn't know about it and go unused, but maybe we have bits in an address overflowing or something.
Is ledstrip_feather a reasonable starting place?
Is there much documentation on memory maps and sector layouts and such? Even pointers within the code would be helpful it looks like we kind of magically appear in main() and I don't know my way around the pio build system to know where that '4mb' entry comes from.
Does anyone with a working S3 configuration have the chance to trade binaries with me? Are all the S3 boards "compatible enough" to at least boot and hopefully not get stuck spin-waiting an LCD control panner or touch input or something? (i.e can you boot a Lilygo T3 build on a HiLetGo or a Ledstrip_feather with each other's boards and binaries?)
This is the kind of thing that will PROBABLY be a three line change somewhere. Until then, it's like diagnosing a baby from just a cry or a car from just a "check engine" light.
Beta Was this translation helpful? Give feedback.
All reactions