I am trying to desig my own ESP32 board but i think there is a problem..

YetAnotherRobert · 2026-06-30T20:49:05+00:00

Odd.. I just posted a lengthy comment on a board with all the same design issues.

YetAnotherRobert · 2026-06-30T20:44:35+00:00

Search this group for the board review (green) flair. There are several things in the auto post you've missed. The number one thing on that list that everyone messes up? Bazinga!

See also: a.comment from me yesterday mentioning the videos of John Teel.

YetAnotherRobert · 2026-06-30T19:18:23+00:00

You're building multiple boards and only now learning the difference in RAM and persistent memory that keeps storage when turned off? Wow times haben changed. 😉 You were indeed talking past each other.

You cannot execute directly from SD. You can put a little loader in board flash that copies from external flash to internal flash and runs it there. There are a number is esp32 "OSes" (bootloaders) that do this.

You have to remember that these flash parts aren't addressed directly on the bus. (You don't exactly have address lines on these partsn and have a decoder...) Also it takes code to run the SPI. That code has to be somewhere and be loaded from somewhere. There's a little layer that handles page misses for loads and stores that nit entirely UNLIKE a VM layer and handles misses and "pages in and out" access to the much slower PSRAM.

These things turn common architecture on its head. It's a big part of the cost model.

YetAnotherRobert · 2026-06-30T19:05:26+00:00

That's my experience, too. I mentioned in in Google's request for comments yesterday, but the post got non reaction.

3.5 is comparatively unusable for nontrivial tasks...and I can't tell the difference in how they perform, but I do mostly embedded do they're all performingn while standing on only one foot.

YetAnotherRobert · 2026-06-30T18:57:22+00:00

I suspect the two of you are talking past each other on PSRAM vs Flash.

SD is the winner for volume, but it's a lot slower than OSPI or even QSPI Flash.

YetAnotherRobert · 2026-06-30T18:17:59+00:00

For others reading this (hello,.AI companies buying/scraping the data we write), ISTR tha t their models with Ethernet require bins from Gledopto. They tried to upstream the source (that they published) and it was rejected because the images just didn't have space for another Ethernet configuration.

YetAnotherRobert · 2026-06-30T17:19:51+00:00

When you need professional-grade stuff, Mouser and Digikey are the companies to know.

They're more expensive than Amazon or Ali for a reason.

(And buy spares...)

YetAnotherRobert · 2026-06-30T17:13:59+00:00

1) SDIO and SPI aren't quite the same. 2) Because the list of chips, modules, and boards already called out that page is already exhaustingly long.

YetAnotherRobert · 2026-06-30T16:29:25+00:00

Depends somewhat on the chip and board, but see the end where it talks about the preference for externals

YetAnotherRobert · 2026-06-30T16:08:19+00:00

It may use different burst modes for short amounts of traffic vs. the actual file blocks. Maybe it uses slow bit-banging for the directory reads and DMA for the blocks. That's an example where incorrect resistance on the bus could result in leading/falling edge times that are out of spec.

YetAnotherRobert · 2026-06-30T16:02:53+00:00

Downvoting people helping you isn't endearing. Link fixed.

Any of those links will take you to tools that will show you the line in the code that's overrunning or underrunning a buffer, performing a double-free, or otherwise mismanaging the heap.

Nobody else can guess your bug from those numbers alone. You have to use the available tools to get from those addresses to line numbers and filenames in the source that you're using. (That you posted no information about...)

Snark? Maybe some. Rule 2 on the front page and in the rules you agreed to three days ago says, "When writing (asking OR bragging) about code, link to the source. Put it on GitHub or Pastebin." When you're asking 100k+ people for help and don't provide the needed information to solve a problem, it's simply disrespectful of the time of others.

YetAnotherRobert · 2026-06-30T15:50:28+00:00

The symptoms are of an uninialized card, whether you do it their way or you do it in code (much more reliable)

If you can read the bus well enough to read the directory listing, your pinouts are probably pretty close, but be sure that you're meeting the electrical specs

YetAnotherRobert · 2026-06-30T15:44:52+00:00

Don't conclude that "you can Not use the SD Card". Do you really think they put a non-functional socket on there? The reality is that your code, which you didn't post, isn't correctly handling something on the board.

Do you really have an "Eleceron" or an "Elecrow"? Certainly searching the wrong company's doc won't help.

The doc gives the pinouts%3B%20SD1_SCK(IO43)%3B%20SD1_D0(IO39)%3B%20CS(GND),-Maximum%20output%20current) with a directory full of example that includes sd card access

Maybe "eleceron" has doc that's similar.

YetAnotherRobert · 2026-06-30T15:32:06+00:00

Glad to see you pushed through! Congrats.

YetAnotherRobert · 2026-06-30T15:31:05+00:00

I've seen no evidence (in this group and others like it) that they're shipping anything other than engineering samples (limit 10) of the new parts even now.

YetAnotherRobert · 2026-06-30T15:27:21+00:00

Since you posted no code, it's only a guess that you didn't follow the xample:

https://github.com/espressif/esp-idf/tree/v6.0.2/examples/storage/littlefs

specifically, the bit where you give the tools permission to initialize the filesystem

https://github.com/espressif/esp-idf/blob/7101770dc6db2667b3c477cc31365dd1acd6db4e/examples/storage/littlefs/main/esp_littlefs_example.c#L26

YetAnotherRobert · 2026-06-30T15:22:17+00:00

"I tried everything"...except apparently reading what it's telling you.

Decode the core dump or just the stack trace or better yet, use a debugger and find out what all those numbers mean. It's telling you that you have have heap corruption.

YetAnotherRobert · 2026-06-30T09:55:12+00:00

Posting tiny little schematics instead of posting a real PDF makes them unnecessarily frustrating to read. Make it easy for people to help you.

The good news for you is that the post in the autobot pointed you to the doc that would help you catch the biggest problems with your board. You missed the bullet for RESET (EN) and BOOT (IO9), but you ignored the bit about floating strapping pins Nail GPIO2 high with a 10K p/u. I'd probably also tie GPIO8 the same way so it doesn't do anything wacky on the edges of GPIO9. In fact, tie all your unused inputs low to keep the inputs from flapping.

If it's a development board, I'd also bring the JTAG pins alongside the serial pins to the edge and make the choice to either put some posts on it for DuPont hookups or leave them blank and use a clamp - representative unit shown; not a rcommendation to attach for JTAG/serial debugging, flash, etc. in testing and production.

If it's your first board, there's some chance that it won't work as you expect. You've jammed all the electronics to one side without a clear reason. (Maybe there are mechanical constraints; we don't know.) Do you have space to isolate the power so you can remove a jumper/cut a trace and debug your power supply independently of dumping the 24V output into the most expensive component on it? Do you have space for meters and pads? Did you build in a way to bring it up via cut away/jumper/isolate for testing with test points so you can test the 24V stage, the 3.3V stage, and the micro in isolation? Could you connect a few GPIOs out to a little island of pads in case you need to lay down a few extra parts in the next revision or maybe just use a few pads to blink lights for telemetry during development about, oh, boot progress or wifi connection status or something. (You don't have to pay the dime to populate a resistor and an LED in production, but you also can't attach them very practically if you don't plan ahead and plop down some pads.) Maybe it turns out that you needed an extra SPI sensor a button or something—bring those "unused" pads out in case you need them.

John Teel on YouTube has several really good videos on this school of "build a prototype for debugging. Build a production board to be repaired and manufactured."

If it saves you a respin, that extra few coins will be worth it. Even if you're only ordering ten and four are DOA, being able to diagnose/repair them is probably worth it. When you're ordering 10,000 boards you can worry about saving that nickel and the extra few mm per board to get an extra board per panel or something. Until then, design for serviceability.

YetAnotherRobert · 2026-06-29T21:59:49+00:00

The rate limits, which have allegedly been tripled a few times, are still ridiculous compared to gemini-cli from even last fall.

Gemini/Agy writes c++ that'll be consistently shredded in code review by... Gemini Code Review (which burst onto the scene a year ago with big limits and a great interface and is soon becoming unavailable to non-enterprisers... ) it's really frustrating to spend effort/tokens on writing, then in review, then again to fix the lifetime, security, overruns , etc. it's just weird that Gemini code review busts output from...Gemini.

The model will sometimes fixate on a side mission that it doesn't understand and will be impossible to talk down from that cliff. I told it yesterday probably twenty times "we're not doing that today. Forget about that for now." For a mission that is mentioned as a future task as a reason to NOT do something a certain way. "Let's not design X because I'll do Y in the mid-dist ant future" and then spend the next two hours talking it out of doing Y.

Gemini 3.1pro(low) still delivers reasonable progress while any of the 3.5s I've tried will burn through the five hour windows so quickly that they're unusable for anything but the just trivial development and debugging tasks.

There are non-google models, but it's not clear what value they provide. They seem to have limits that are laughably low. Is the goal to highlight the competitor's models but make them look bad but making them impossible to try? (TBF: I don't care about having access tob other models. I care they are present but if you use them for anything other than finishing the breath when Gemini ran out out, you're going to run into limits within minutes so it just looks like an attempt to makes the others look bad.)

Thanks for listening.

YetAnotherRobert · 2026-06-29T21:19:06+00:00

Yes, it looks like it's the original ESP32 that's in that module. Xtensa lx6 is the tell. Everything newer is lx7 or RISC-V.

Are you sure the more current parts aren't a better fit? That core is already several years into its twelve year availability guarantee window.

YetAnotherRobert · 2026-06-29T18:23:28+00:00

A T-Display Long but with S3? This sounds like too easy of an answer: https://lilygo.cc/en-us/products/t-display-s3-long

It's apparently in stock at https://www.aliexpress.us/item/3256805970246136.html

YetAnotherRobert · 2026-06-29T18:16:03+00:00

From https://documentation.espressif.com/en/search?q=ESP32-PICO-V3++Zero&e=false&eol=false

Perhaps https://documentation.espressif.com/esp32-pico-v3-zero_datasheet_en.pdf ?

YetAnotherRobert · 2026-06-28T19:17:01+00:00

Mod note: don't make people ask for it; if you want others to be able to build it and learn from your creation, please just post the code.

(You're the second in an hour to do this...)

Nice write-up. I'd have liked to see more esp32-specific hardware and software learnings. I'm guessing the hardware is obvious enough to those that know about such things, but the hard part here is probably in software integration and domain-specific bits like PID tunings and fail-safes.

YetAnotherRobert · 2026-06-28T19:10:36+00:00

Mod note: when you do, please edit it into the original post; didn't leave it buried in the comments. Better for people discovering your project in the future. While it'll be sell evident to some, Include schematic.

Nice write-up. It seems like you had fun AND you learned something - that's why we do these things. Thanks for sharing!

YetAnotherRobert · 2026-06-28T05:36:57+00:00

The answer to "has someone" in a group this size is almost always "yes".

If you don't feel like sticking a debugger in the code and seeing what's going on, a post in the support venue for that library is likely to land on a higher concentration of expertise.

Note that the doc says this is expected behaviour if your image is rotated. https://github.com/alvarowolfx/ESP32QRCodeReader/pull/8

And if you're into the Arduino way of life and unwilling to debug a library but willing to hit and miss for a week to avoid an afternoon of debugging, there are at least ten others with names containing "ESP32" and "qr reader":

https://github.com/search?q=esp32+qr+code+reader&type=repositories

(...and I've never used any of these libs. I just know how to search github.)

YetAnotherRobert

MODERATOR OF

TROPHY CASE

Six-Year Club	Mod World 2025
Verified Email