Hello, I took up John's offer to help try to figure it out and had a great time working on it with him today. I've put the Kicad files up on Github if anyone else wants to take a look ( https://github.com/charlesrwest/GoodBotControlBoard). Initial conclusions are below (John is welcome to double check my notes if he wants):
1. The power line feeding into the linear regulator that feeds the microcontroller on the board is fairly noisy. This noise gets significantly worse when the Nano is drawing larger amounts of current. 2. Adding a large capacitor on the microcontroller side of the linear regulator did not seem to help. It still started acting weird when the nano booted. 3. It appeared that the 5 volt buck regulator in the board was the primary source of the noise. 4. Replacing the large capacitors in the 5 volt regulators seemed to significantly reduce the noise (around half as much?) but didn't solve the primary problem. 5. John discovered that the buck regulator had a number of different modes it can operate in. Some are more likely to produce high frequency noise than others and switching to a different mode might help. However, switching a resistor appears to have somewhat changed the output voltage to 5.5 volts, which makes it unusable for the Jetson nano (but it wasn't working anyway and John came up with a work around, so no biggy). 6. The big capacitors for the motors are probably too high ESR and I should look into replacing them if possible (and doesn't kill price). 7. The linear regulator for the microcontroller should probably be replaced. It is probably near its limits with the current voltage drop and current draw. 8. It would probably be a good idea to isolate the voltage sources from each other using something like passive t filters in the next design. 9. If powering the nano with the buck on the board kills the MCU, maybe don't do that? A temporary solution for the demo may be to reuse an old 5 volt buck module to power the nano and leave the buck on the board idle. 10. The buck on the board might be overpowered for what it is currently being used for and that might be a partial cause for the noise. @Trampas: You are 100% correct and I thank you for the offer to use the O-Scope. It was the MVP working on this today with John. Your solution is also more or less what I'm going to do to see if I can get it demoable. Thank you. @Nick: I think it's more of a power for the boards than control signals issue. Also thank you for the battery offer. However, I think I would have to redesign the chassis to make that work. @brian: 100%. The power is not stable and needs to be figured out. I'm gonna try to patch it to see if I can get it demoable and then do a redesign (John's offered to review) to try to get it stable. I don't think it's the firmware (this time) because the serial communication between the nano and the microcontroller had been disconnected. The only possible way for them to effect each other right now is through the power rails. Thanks, Charlie On Sat, Mar 23, 2024 at 12:46 PM Brian via TriEmbed <triembed@triembed.org> wrote: > Hi Charles, > > Hearty +1 for everything everyone has said so far. Trampas in > particular for suggesting you use a scope on your power rails. Most > DMMs do quite a bit of filtering (even if it's in the form of a very > slow sample rate) and can't tell you about high-frequency trash on the > supply rails (or other lines) that can wreak havoc with sensitive logic > systems. If your DMM has a DC+AC mode, try turning that on and seeing > what it says is the AC component of the power supply as an intermediate > step. > > Definitely make sure your power is good first; if your power isn't > stable, all other bets are off. You want to see a nice flat line with > minimal ripple. Make sure you zoom right in on the time axis to see if > there's any high-frequency garbage. Also measure as close to the > consumers of power as possible (i.e., at IC pins, not at the regulator). > Note that DC-DC converters tend to have relatively high amounts of > ripple; the 3v3 regulator will filter a lot of that out, but if anything > is being fed directly by the 5V supply, you might need more filtering on > that rail. > > Following that, I'd check your ARM firmware for things like polling > loops without adequate timeouts when talking to off-chip peripherals. > The fact that everything is copacetic until the nano is in the picture > makes me wonder if perhaps the ARM core is getting stuck waiting for > communication with the nano to finish (assuming they are talking to each > other). If you're doing time-critical tasks on the ARM and aren't > already, I suggest picking an RTOS (I'm partial to FreeRTOS mainly > because of its use on the ESP32 product family; several are available > directly in the STM Cube IDE) and learning how to prioritize > time-critical tasks so that unpredictable asynchronous communication > issues won't get in the way. > > This is, of course, all very generic advice based on knowing absolutely > nothing about your design. :-D Just stuff I've run into on my own travels. > > Cheers, > -Brian > > > On 3/23/24 07:07, Trampas Stern via TriEmbed wrote: > > Charles, > > > > The problem could be several things, the best thing to do is put an > > oscilloscope on the power rail and see if that is the problem. I have > > an oscilloscope you can borrow if you need one. > > > > The problem could be many things from noise on ground, to noise on a pin > > on the micro, or noise getting to crystal for the micro, again an > > oscilloscope will help. However good diagnostic techniques can be > > used. For example if you suspect it is the power supply, remove the > > 3.3V linear and power the 3.3V from a bench supply and see if the > > problem goes away. This does not tell you what is wrong with the 3.3V > > rail but lets you isolate the problem for more investigation. > > > > Trampas > > > <snippysnip> > > _______________________________________________ > Triangle, NC Embedded Interest Group mailing list > > To post message: TriEmbed@triembed.org > List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org > TriEmbed web site: https://TriEmbed.org > To unsubscribe, click link and send a blank message: mailto: > unsubscribe-triem...@bitser.net?subject=unsubscribe > Searchable email archive available at > https://www.mail-archive.com/triembed@triembed.org/ > >
_______________________________________________ Triangle, NC Embedded Interest Group mailing list To post message: TriEmbed@triembed.org List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org TriEmbed web site: https://TriEmbed.org To unsubscribe, click link and send a blank message: mailto:unsubscribe-triem...@bitser.net?subject=unsubscribe Searchable email archive available at https://www.mail-archive.com/triembed@triembed.org/
