Let me take this thing apart real quick and clean it out, it does live in a shop…and been to three shows in the last couple months. It has a hard life. BRB
So, just to clarify:
ESP32 plugged into USB and connected into the board.
+24V power to the board.
Turning off +24V power to the board causes the laptop to lock up reliably?
Trying to figure out what the power flow will be during that situation. I can’t see that it’s likely to be anything pulling the 5V up, and if it were I wouldn’t expect that to be crashing anything anyway. Perhaps damaging the power control IC on that port under the most egregious scenarios, but not crashing the laptop.
Pulling the 5V low would potentially cause issues on the laptop, but usually the USB controllers disconnect power or have a PTC that will trip and prevent that. If that was happening I’d expect that the USB port would appear dead (sometimes coming back to life later), not just to be fine and continue as normal. This has also gotten way less likely with later higher-current versions of USB.
The other weird thing is that the 5V from that SMPS really shouldn’t be doing anything when the board is connected to PC power It should just be idling at 5V, without enough voltage to forward bias D1. If that 5V drops, there’s nothing there that is going to be particularly worried. Almost all of the logic is at 3.3V, which is being supplied by the regulator on the ESP32 anyway. (Which is worth noting, those regulators are often running somewhat on the ragged edge anyway, so it’s worth checking their case temperature given the extra 3.3V load from all those other devices).
Another slightly more off-the-wall suggestion is that I would carefully and manually check the pinout of your ESP32 dev board vs the pinout used in the schematic. There are a few different versions that aren’t pin compatible which could cause some weird issues, too.
Obviously that’s a bunch of musing about what should happen when it’s working. Given that it isn’t, that’s a good indication that something is wrong with the logic above, of course.
Definitely leaning towards something like @RockinRiley’s suggestion of isolating the 5V from the PC in some way (or better yet, removing D1 from one of the boards as a test) just to provide a bit more confidence and let you get through to the next step. This is one of the downsides to using an ESP32, there’s no way to make them solely target-powered and not power them via the PC at all.
Okay it is back together and under load. Much better. It was actually spotless inside, including the fans.
Turns out it was a power setting I changed at the last show. It was way off. It is barely even warm now like normal. Funny thing is I had it set to use less CPU, turning it back to normal fixes it.
As for why…maybe it was just the straw that broke the camel’s back. Sitting there cooking and a tiny extra load getting pulled all the sudden made it buckle.
The scenario still seems sketchy to me. Pulling power to an external board that has its’ own internal switching power supply to run an ESP32 should not be a repeatable way to lock up your laptop.
But, if the laptop was in a really weird state and was that far on the edge… maybe.
Probably want to repeat that test scenario a bit more and have all your beta testers make sure they don’t have similar issues. If it is at all repeatable then it is a problem and will cause issues for users of the board.
yes, to the tripping the usb circuit, had that happen before!
So I am concerned about the fact that just changing the Power settings changing the pc to not lock up. And the heat.
Did you look at the event log in computer management to see if there was any evidence of what happened? Sorry, east coaster here had to go to sleep on you. Glad it is working, but just does not seem correct. The log to look at would be the system log. (For future the stuff you do, that app log may be of use to you as well.)
I can take a deeper look.
It’s a dell, and it has dell power and cooling settings, on top of the windows settings. Each time the error was the same, driver state I believe. I was on adaptive and that said allow it to run warmer…no good.
I will hook the 5v rail to my scope to verify there is no spikes for sure. I am pretty sure it was the tiny added load that did it, not an actual spike. The laptop was literally uncomfortable to touch hot. Fans were not coming on
Hey, so on the website for bart Hardware · bdring/Grbl_Esp32 Wiki · GitHub I see the below, is that the board you designed already or is it one that someone else designed?
Never mind, I see it was 3 years ago. Tindie shows it as retired.
I was unaware fluidnc had been around so long.
That was a grbl32 board, not mine. It is kinda close, but they are all based on the same stuff, all of them are just rearranging the modules.
They went from grble_esp32 to full fluidnc not all that long ago. The bones are the same just or course improvements over the years.
Yuck
It happened again…I did several unplugs and plugs though and everything was fine. Checking for updates and maybe run a malware check. I have never had my fan on this much.
Fresh reboot and there is 7GB of memory in use. Don’t see anything here doing that. Fell like that is out of the norm.
Something definitely “smells” funny about this…
Do you have a simpler machine you can risk that would eliminate some variables?
Electronic issues like over voltage don’t usually crash software. But software only runs on hardware. So when you go out of spec, the results are “undefined”. Which means you can’t really be sure what will happen. If the USB rail was connected to some other peripheral that was on the PCI bus and it reset while it should have been working, then it can feed garbage data to the cpu, which could definitely result in a hang. That feels like a long shot. I hope hardware manufacturers isolate different components like USB from PCI better than that. Especially because out of spec USB devices are coming from China by the boatload.
what is that bugcheck, that is the one to look at.
dcoms are very prevalent, nothing realy. Looks like there is Power mgmt there to TPM and your network maybe went out, do you have a dock connected?
also what is Killer Network Service and Killer analytics?? Those are services running right now.
LOL - you have a team of engineers here helping to debug issues with your windows notebook.
Suggest plugging custom prototype boards into some other computer besides your primary laptop.
Here is a pretty darn good computer from Odroid:
https://www.hardkernel.com/shop/odroid-n2l-with-2gbyte-ram/
When researching running klipper on esp32, jeffb appears in the following thread:
https://github.com/Klipper3d/klipper/issues/199
@jeffeb3 do you have any updates on running klipper on esp32?
In my case, Killer Network Svcs is the Acer Networking “tuner” that supposedly does QoS tuning for network traffic. So your gaming and video streams remain as fast and low-latency as possible.
Okay, I looked at the updates that ran when I got home. There was a BIOS update. So I looked in the BIOS and I see the C-States settings was off. So the processor was running at full tilt and the fans were not coming on. Hopefully betwean those two settings I hope that is set.
I will find out shortly.
As for the laser troubleshooting, they gave me some feedback so I will update that as well and try again.
Slow and steady, I am trying to think through every step.
No. I never tried. It shouldn’t be that hard to get something working. The mcu coffee can be pretty simple. But I never had an interest.
So, I did not think that I had seen esp32 on anything for klipper, I found this. If you believe what they say, it is not supported, and I guess when I read this, why would you? The Fluidcnc seems to do most/if not all that Klipper does.
https://www.reddit.com/r/klippers/comments/vy4qs5/esp32_klipper_microcontroller/
After doing a little research on klipper support for esp32, I found that:
Klipper developers are complaining that due to latency in interrupt handling, the esp32 is not supported. It is likely that the arduino abstraction layer that invokes the expressif api is the source of slow interrupt handling, or rather, slow performance in sending out motor control signals.
With esp32 grbl and the Bard Dring controller, the stepper motor signals are driven with the esp32’s onboard hardware i2c controllers that send the stepper motor signals to serial-in parallel-out shift registers on the fluidnc controller board. This is a very high performance method that does not use software to send the signals out to the motors.
Basically you should be able to write a interrupt handler that just triggers the i2c to start shifting out bits when the timer matches with a scheduled frame of data to send to the motors.
I’m going to fork the klipper code and try shifting out serial motor control signals with the i2c controller. It would be nice to have a uart fluidnc controller to test with tmc2209 drivers. What is the availablity and cost of the fluid nc controller?
I only have 4 left. I can send one out but I would like to get the fluidnc part working first in case there is a hardware issue. Sounds like today might be a productive day in terms of fixing issues as our schedule seem to be in line finally.
Actually I have four of the first revs as well. Those will be fine for testing, they are just 100 bigger and the VMot Output is not the same. But it will allow for testing if you want one of those.