i’m coming to you to because i find some little problem about the Jackpot board electronic design
i trying to make workable my MPCNC since 1 year.
and desipte eight ESP32D WRROM changes and a full TMC2209 changes
i still got weird steppers behaviours
i am electrionician, so i start to take a watch on the CAO schematic
and i find something strange witch is certainly the main reason of the issue:
you use 3V3 for quasi every thing on the board from the ESP32 DEv kit 1117 LDO
the max output curent of the ldo depend of the LDO brands and quality and can vary between 700mA to 1.2 A
I did a quick calculation ; all the drivers, multiplexers and leds can use around 350 to 400 mA
an ESP32 WROOM with Wifi can consume between 240 to 700 mA current PEAK
with this data i can tell the ESP 32’s LDO regulator is clearly undersized
the 5V LDO TPS54360 you used on the jackpot board can deliver 3.5 A
why don’t use this curent buffer ?
this just a feedback to help and contribute
i thing that surely why we have some weird behaviours between different Dev kits
What would this look like?
Keep in mind I have next to zero experience with circuit design. I am very interested in making the most stable board possible.
I have not really heard of any stepping issues but I am sure there are changes that can be made to make this more robust. The only consistent thing I notice is the boot/flash behavior, I am not sure why some need the boot button to be used and some do not. I suppose this could be a power thing but I doubt that.
Hold up, something’s not adding up here. I’m pretty sure I went through that power budget for the 3.3V rail and didn’t see an issue.
Can you share that calculation? I don’t get anything anywhere near that. LEDs around 2.5mA total, buffers around 15mA total with a VERY pessimistic reading of the deltaIdd spec, drivers are nothing, maybe a few hundred uA.
Yeah, peak during transmission, not average which is what we’d be sizing the LDO for. The LDO doesn’t have the output bandwidth to be supplying WiFi transmission peak currents, that’s handled by decoupling/bulk capacitance.
I don’t see any issue with this, but I’m far from convinced that this is needed. The shift register input voltage thresholds are 3.3V compatible when on 5V supply so either way should work fine. TMC2209 Vdd and Enable lines would need to be pulled to 5V as well if this change was made.
That is incorrect.
Recommended Vcc range is 2.0V to 5.5V. This chip is fine on 3.3V
The TMC2209 is not running on 5V, it’s running on Vmot with the Vcc_IO input logic reference voltage set to 3.3V.
This is also fine:
I/O supply voltage: 3.0V - 5.25V
I don’t inherently see an issue with swapping the drivers and shift registers to 5V but I’m a LONG way from being convinced it’s needed. So my perspective would be that this isn’t enough of an issue to be worth revising the design and that any potential issues that the original poster is seeing should probably be chased down to see what’s actually causing them because I’d bet good money it isn’t the Jackpot’s 3.3V draw…
This is a super basic power rail stability question.
To measure this you’d probe the 3.3V rail and verify whether it’s stable +/- 10% during operation. If there’s a serious issue, you’ll see the 3.3V rail have dips or clear voltage changes under load. If the problem is more subtle then you’d need to set the scope triggers to catch it and put the scope in one-shot or normal/trigger mode (not untriggered roll, whatever your scope calls it, it varies).
It can be a bit tricky because edge triggers can be very dependent on rate of change so you might need to sweep the timebase around a bit and change the trigger voltage until you’re catching something.
A more major version of this would be the LDO overheating and going into overtemp shutdown, which would look like a complete 3.3V power cycle.
Honestly, though, I’d have thought if it were actually a major issue we’d be seeing brown-out detect triggers on the ESP32 itself… I don’t know what that threshold is or how good the on-chip BOD is though so who knows.
I think that’s largely just down to the way that the ESP32 handles the boot state of the USB interface. If the chip is unprogrammed, it comes up in USB serial bootloader mode. If it’s programmed then it jumps straight to executing firmware which means you need to hold the boot button and reset the chip to get it back into that bootloader mode. If you’re seeing unpredictable behaviour it may be that some chips have been programmed previously and not fully erased or something. Perhaps a self-test routine that runs once and on completion sets an internal kill switch to prevent it running again, rather than a test rig that fully erases the chip afterwards.
In the ESP32 Xiao modules I’m using I can program them fine the first time but subsequent programmings need the boot button held while resetting.
I seem to always have to push the boot button when flashing, even on a genuine Espressif devkit. On my wireless pendant thing, I put a 10 uF capacitor between EN and ground and I no longer have to do that. I read that somewhere but couldn’t find it again. In my specific case, this is important because of how the ESP32 is mounted, I don’t have access to the boot button without disassembling it.
Does this just add a slight delay? Mitch thinks we should move our UART to other pins to be safe.
Thanks for taking a second look Jono!
I do have a couple changes I would like to make so maybe we can do a deeper dive when we all have a little free time and see what can be done at the same time.
Might be worth being a little careful on that change. I don’t generally like slowing down the edge rates on digital inputs too much as it can cause odd behaviour or lead to electrical latch-up in the worst case. I would hope that the ESP32 would have a fair bit of hysteresis on the enable pin but I don’t know.
If the reset tact switch is directly across that 10uF cap then it’ll need a resistor in-line to current limit, too. 10uF is a big cap to be dumping into a tiny contact like that.
