Well 1 actual bad one the others seem to do everything else fine just not fluidnc, a lot to learn yet. I just set them aside to look at later. Time wise only about a minute each is wasted, less probably. I just flash test and go. I don’t sit and wait for things to happen, I keep moving.
I am working on a schematic right now, but most of my time has been spent trying to figure out which one to base it on. I think I am going for the esp32-wroom-32E (N4/N8). E is supposed to be the current version but all the same functions…who knows. Worth poking at the schematics look the same with a quick glance.
I don’t know enough about this stuff and I can’t just learn it reading the docs page I have to “make” something to not skim over little choices (like capacitor type).
Interesting. The -S3 moves up from the LX6 core to the LX7.
Those can support up to 1Gb of PSRAM (!!!)- but I can’t quite tell from the comparison if there’s variants with built in PSRAM.
Also interesting is that the dev board for the -S3 has dual USB ports, which might be a boon to those wanting to leave a controller permanently hooked up to the UART.
After looking at the specs of the -S3 in the post above, that would be a pretty interesting part long term.
Maybe for the 2nd revision of the V1 ESP-32.
I bet you’d get pretty good support here if you were to embark on a V1 variant of ESP32. There’s a lot of enshitification in the ultra-cheap dev boards, just using decent (but still inexpensive) parts would likely make them much better behaved.
What’s the specific issue here? Have you done anything to conclusively show that this is the issue? Is this something you’ve tested or just a hunch?
From looking at the Espressif docs, it appears that GPIO0 just needs to be held high at boot, either by its own weak internal pull-up or by whatever it’s externally connected to.
The easy approach to pins like that is to use them as outputs and make sure that they’re ok with being pulled in the right direction during startup. I would have said a UART Tx was a very good option there and this looks pretty similar to how I would have approached it.
I might not have a complete enough picture of what’s going on here, but I certainly don’t see anything here that would convince me that a layout change needs to happen. Some extra investigation or a couple of changes to components etc. to verify things, sure…
Now that we added the pullup, they all boot and flash perfectly fine. Now the odd boards are showing weird $ss messages. So Now I am getting more and more “bad” esp’s because I am not going to ship them if they repeatedly show incomplete $ss messages. Oddly Sometimes they work perfectly fine…after making stepper move a bit.
This does also vary when the Steppers are connected or not sometimes. So it is either a bad pin choice, or that pull up is too strong? Not sure. Or are these esps that are just bad and without the pullup they would not have flashed anyway. Was the pull up a waste?
How would I test that. O-Scope the TX and RX pins and look at the signal?
Logic analyzer?
I guess that could be a good first real test. Currently, I am just making a pile of funky esp’s that almost work. Not seeing any obvious resistance differences on the good and bad gpio0 pins. Maybe I should also check the Rx pins.
From the driver spec sheet “Baud rates from 9600 Baud to 500k Baud or even higher (when
using an external clock) may be used. No baud rate configuration is required, as the TMC22xx
automatically adapts to the masters’ baud rate”
What do we actually need in terms of speed? This is all I am seeing regarding speed Axes | Wiki.js
So the pull-up was added at some point partway through and that fixed the booting issue? That would make sense, the internal pullup will be extremely weak and needs to be able to charge whatever capacitance is connected to the pin before the boot occurs.
As in there are some boards doing this or are these the same boards that were showing issues before? How is it weird? Garbled characters, missing sections, starts responding partway through? Does it only do it to the first if you repeat the message a few times?
That does sound odd. I think it’s important to try to accurately verify exactly what the failure conditions are and try to nail down exactly what affects it. If you’re trying to keep combinational stuff like that in your head, it’s possible to get lost in confirmation bias. The best scenario is if you can reduce it to a specific course of actions that make it fail 100% of the time. Something like ‘If I power up the board from cold and $ss doesn’t respond with a complete message, I can move a stepper motor and then $ss will always respond with a complete message’. That’s something you can start to tease out the different effects and see where they’re related. On the other hand, if it’s ‘I power up the board from cold and if $ss doesn’t respond properly, moving the stepper motor and then trying $ss will respond correctly 50% of the time’, then I’d say they may not be related and just to try it again without moving the stepper motor. If it’s a case of moving the stepper makes it work 50/50 and not moving the stepper means it works 0% of the time, that’s still a valuable thing to know, you just need to do it 10-20x as often to be sure that it’s actually a real effect and not just luck. Otherwise it’s like flipping a coin 10x and concluding that because you’ve only seen heads that your coin is broken!
A bad pin choice doesn’t sound right, to me, but I learned long ago that it’s always better to devise a test procedure to prove that it’s not something wacky than to discount it outright. Obviously test the easier/more likely stuff first, but never discount something because it ‘surely can’t be that’, etc. Pull-up too strong is definitely possible, I’m not super familiar with the drive strength of the ESP32s. This is where I’d normally say that’s an easy test by getting a scope probe on there and taking a look. Alternatively just drop it to 10k or even 22k and see what happens. Is that something you’re able to do?
Exactly! It could well be some kind of power supply issue causing a slow voltage rise on startup that changed the balance with that weak internal pull-up. It could be something entirely different.
I would never say it was a waste. It may not be needed, but everything is always a balance. Putting it there isn’t a big cost driver and is a conservative/defensive design decision. It may make zero difference, but if it doesn’t then you’ve only spent a couple cents extra per board. If it prevents problems even 1% of the time, it will be worth its weight in gold. Also considering that things need to be thought of as 'does it work on my bench, on someone elses bench, on 12V vs 24V supplies, on supplies with lots of ripple, in places with significant EMI, when the ESP32 is cold, when it’s hot, when it’s a cold boot vs a hot reboot, when it’s a hot reboot and the pin might have been at 0V when rebooted or at 3.3V. When the ESP32 input is at the low end or high end of its sensitivity specification, etc. In super detailed high-end designs or where the fix for an issue might be super expensive, we take ALL of that into account in one way or another and devise tests to make sure that things work in all those conditions. In the vast majority of circumstances or if it’s something like adding a pull-up, you add the pull-up and move on with your life. Consider it like designing a bridge. If you’re a hardcore professional and it’s a hugely long bridge on a tight budget, you do a huge amount of design work. If you’re a home-owner/DIYer and you’ve got a small creek to get over, you likely just over-build the shit out of it, slap it once, say ‘that aint falling down any time soon’ and move on with your day!
Could well be. In that case, writing a basic test firmware that just spams a message out of the UART could be useful to see if it’s re-creatable.
Yes to both of those things. Scope zoomed in to check that the waveforms going in/out of the ESP32 are crisp and square-wave looking with no glitches on the edges or ringing. Logic analyzer or good scope with good memory depth and serial decode to see that frames are being formed correctly, no doubled edges, timings are stable, checksums are correct etc.
How are you checking that resistance? I wouldn’t expect that to show anything useful, to be honest.
Another great option. Is this a hardware or software UART in the ESP32? Software UARTs are notorious for falling over at times when the software has too much other stuff going on. If you’re seeing ESP32s fail to work properly immediately after boot, maybe there is some other setup stuff still going on in the background or something that hasn’t timed out completely yet taking up cycles.
Again, separate it into testing vs fixing the issue. For testing, do the most extreme thing. Change it to 9600 baud and see what happens. If the comms issues go away but the drivers start doing weird stuff due to slow comms then that’s a huge win, evidence wise.
The flashing process should include some form of read-back verification step, so as long as the flashing completes successfully, you should be in identical scenarios either way. If the flashing process doesn’t do that, I’d frankly be horrified.
Never garbled. Missing sections if repeated different sections can be missing.
Working on figuring it out. It is definitely not the same for all of them. I was releasing them if they worked with the steppers plugged in. If it took moving the steppers first, that is a bad esp. Now I am holding both for more testing. Testing a couple more things.
interesting.
Okay when I have time to set up and be in a clean space I will dig deeper. I am about to have to make both LR and MPCNC kits that is going to make a mess. Bummer when they run out on the same day.
I found a particularly bad one, I can test the baud rate real quick.
In some ways, asking Ryan to clarify exactly what’s going on is also a bit of ‘rubber ducking’. Having to explain the problem concisely often results in needing to revisit assumptions and can be a powerful way to re-examine a problem through re-framing it.
Okay on this particular one 9600 did not change anything. I tried flashing it on and off the JAckpot, this is a bad board for sure. This is a good one to test deeper for sure. It always shows a lot of missing info in $ss, and most of it, it does not even see the right number of drivers.
Missing entire sections? That is extremely interesting. So where you’ve got a line like:
[MSG:INFO: Compiled with ESP32 SDK:v4.4.4]
You’d be missing an entire line but never part of a line? Is it always the same parts missing, like it misses the first 2 lines?
If so, that doesn’t sound like a hardware issue to me. A hardware issue would be characters missing or being clearly wrong, or maybe an entire segment missing and then coming back but it would be unlikely to be aligned with line ends. After all, there’s usually nothing special about a line from the hardware standpoint, it’s just another set of characters that get sent telling the terminal emulator how to display it and then a pause in the lines changing state, perhaps.
Also,
What the hell does that sentence even say? I can only apologize, I’m currently stuck at home with a fever so who knows what’s going on…
Can you post up a few examples of that? Some context here might help.
For sure, and I do appreciate it. Honestly, I’m not likely to crawl back through them, especially as I currently feel pretty wretched, but hopefully my contribution is valuable enough to be worth the effort to bring me up to speed!
