Of the 8 competitors in last weekend’s Seattle Robotics Society Robothon Mini-Sumo event, 5 of them were Zumo robots:
- 1 original Zumo (Shield+Arduino)
- 1 Zumo 32U4
- 3 Zumo 2040.
All 3 of the Zumo 2040 robots had issues with spurious resets. None of the other robots in the event, including the AVR based Zumos, had the issue. The Zumo 2040 robots would tend to reset when contacting another robot in the ring.
At the event we had 2 theories:
- The impact was compressing the springs on the negative terminals of the batteries which caused the positive terminals to lose contact.
- An ESD event was causing the CPU to reset.
None of us had ever encountered such spurious resets during our previous testing. I have personally created scenarios in my test matches which included much greater impacts than what I saw causing resets at the event. I also couldn’t reproduce the problem once back at home no matter how hard I impacted the bot. I can find little evidence that this was the cause of the problem.
I noticed that the Zumo 2040 robots which experienced the problem the most had headers attached to the expansion ports and/or custom PCBs attached to these ports which would further extend the RUN signal and create a larger antenna to pick up noise in the environment.
Back at home, I have now been able to reset my Zumo 2040 robots via noise and ESD events. If I plug a short hookup wire into the RUN signal of my expansion port, I can easily reset my Zumo 2040 by simply turning on the fluorescent light on my desk and once the ballast kicks in, the bot will reset. I can also simulate an ESD event by rubbing a wool sweater against the steel blade of one Zumo 2040 and then quickly tapping the blade of another running Zumo 2040 against this charged blade. This will often reset the running Zumo 2040. I haven’t been able to reproduce the problem in my home with no extra wire attached to the RUN line but I just think there was just something in the environment at Robothon which exasperated the problem.
My current thoughts are that I might try to modify the Zumo 2040 mainboards to attach:
- A1kΩ pull-up resistor between RUN and 3V3.
- A 0.1µF capacitor between RUN and Gnd.
Thoughts?
On a good note, 2 of the top 3 robots for Robothon 2026’s Mini-Sumo competition were Zumo based:
- 3rd place was a Zumo 32U4.
- 1st place was a Zumo 2040 which actually reset twice during the final match but still managed to pull-off a win.
Hello, @AdamGreen.
I am sorry to hear about the trouble with the Zumos reseting, though I am glad to hear that it sounds like the competition was a success overall!
I suggest starting out by adding an external pull-up. I did some searching on Raspberry Pi forums and that seems to be the more common go-to solution for preventing unexpected resets. The RP2040 already has an internal 50k pull-up resistor on the RUN pin (which is probably explains why we have not to the best of my knowledge seen or heard of this behavior before), but based on your results it seems like it might be a good precaution to add a stronger external pull-up anytime you connect something else to the RUN pin.
- Patrick
Hello, Patrick.
Thanks for the response.
…, though I am glad to hear that it sounds like the competition was a success overall!
Not for all of the Zumo 2040 contestants though since the resets might have been the reason that one of them got knocked out so early.
I suggest starting out by adding an external pull-up. I did some searching on Raspberry Pi forums and that seems to be the more common go-to solution for preventing unexpected resets.
I saw that as well during my research. From my reading it sounds like it is best to get this pull-up as close to the RP2040, and before the outgoing trace/antenna, as possible.
seems like it might be a good precaution to add a stronger external pull-up anytime you connect something else to the RUN pin.
It was definitely worse if there was something connected to the RUN pin to increase its length but one of the stock Zumo 2040s did experience 1 spurious reset as well so the problem can occur on a stock PCB in the wrong environment.
I will try adding the pull-up and the cap on one of my Zumo 2040s to see if it at least corrects the resets that I can reproduce here.
Both robots manage to reset themselves towards the end of this video. This is similar to what happened at Robothon except we didn’t need the extra ‘antenna’ on the RUN signal there. It was even happening to stock Zumo 2040 mainboards there but not as often. Mine experienced it at least 4 times and I only have a female header added and nothing else.
Just to clarify, is that video showing the behavior with or without adding an external pull-up?
- Patrick
Without the external pull-up.
I wanted to get a semi-reliable repro first so that I can retest it after. I will test the pull-up later this evening or tomorrow.
I bodged in a 1kΩ pull-up resistor and a 0.1µF filter capacitor to the RP2040’s RUN trace. I haven’t been able to reproduce the problem on this modified Zumo since installing these bodges.
Oh! I was imagining you’d start with just adding a connection on the expansion port between the RUN pin and the 3V3 pin using a through-hole resistor.
I did some experiments here myself to find a setup that consistently caused the Zumo 2040 to reset. Ultimately, I did it by attaching around 3ft of jumper wire to RUN and turning a nearby 3A load on and off to trigger the reset. With that setup I found that connecting a 1k through-hole resistor from RUN to 3V3 pretty reliably prevented resets, so I suspect something like that will be a sufficient solution for most people who run into this. (Though your modification is likely more robust!)
- Patrick
Oh! I was imagining you’d start with just adding a connection on the expansion port between the RUN pin and the 3V3 pin using a through-hole resistor.
I took this approach since I wanted a solution that was most likely to eliminate this problem if I used the robot in a competition again. One of the Zumo 2040 bots that experienced the problem at Robothon had nothing extra connected to the RUN pin and even mine only had the 2x14 female header added (and I had nothing plugged into that header).
Ultimately, I did it by attaching around 3ft of jumper wire to RUN and turning a nearby 3A load on and off to trigger the reset.
I am surprised that it took 3ft of jumper wire to reproduce the problem. Here I can use a 6" hookup wire looped back and taped to the back of both robots. I can then run the 2 Zumo robots against one another and usually within a minute at least one of them will reset. The humidity in my house is >= 50% right now. I would have expected it to be even dryer in Las Vegas but maybe your workplace takes precautions (like humidifiers, ionizers, etc) to reduce ESD within the building?
With that setup I found that connecting a 1k through-hole resistor from RUN to 3V3 pretty reliably prevented resets…
It is good to hear that the same solution worked for your scenario as well. I am feeling pretty confident that this was the cause of the issues at Robothon and we now have a solution. I just wish I had been able to perform these experiments on the day of the event to know that it actually worked there as well.
Thanks for looking into the issue on your end as well. I appreciate it!
