Loop stopping - Power issue?


#1

Struggling with a transient issue. My app simply scans for BLE devices then sends various related data to an MQTT server over TCP. I’m Sending ~150 bytes per transaction and 5 transactions per second so a total of ~750B/s so not a lot of data.

At random times the loop() will just stop and requires a reset to regain function. Other callbacks operate normally while the loop() is non-functional.

~45 seconds after the loop() stops the board will reset by itself. I suspect there is a watchdog getting triggered somewhere because it’s consistent. The reset reason is “PANIC” and just before reset I get a hard fault SOS.

My theory is this is related to power. With my scope on the 3.3v pin the failure of the loop() always coincides with a dip in power. Dips of the magnitude shown in the attached do happen at other times without this result, however the stopping of the loop() always coincides with the power dip.

Another reason I believe this could be power related is that across 20 Duo boards some exhibit the issue frequently while others very rarely.

Does the above jive with any known issues in the community?

hardfaultdip


#2

Hi @paulito240,

and

I think that might be the problem on the software side. A power failure won’t result a SOS. Try decreasing the data rate, or even commenting the MQTT functionality to see what will happen.

Best regards,
guohui


#3

Just seems too random for code to be causing this. I can’t tie it to any specific function or sequence and again I have some Duo boards that rarely glitch. Same code.

I just dug up a 200uF cap and put across the power and it seems to have made a huge difference. The difference with and without is striking so I think there is something to this. One of these Duos will have the issue almost as soon as it sends tcp data but with the cap its been going for 30min. I’ll investigate further tomorrow and report anything new.


#4

Looking forward to your report! :wink:


#5

I can reproduce the stopping of the loop() 100% of the time by creating transient voltage drops at or below 2.22V. The duration needs to be between 500us and 1ms. Why this just stops the loop() and not trigger a reset or brownout detection is that I believe the WiFi/BLE radio is the one that is affected by this and not the STM chip.

In looking at the scope during my program execution, only drops below the 2.2V threshold will stop the loop(). The drops do not appear to coincide with specific operations in my code, but again it is hard to sync my code execution with the scope trigger with exact precision. Given the randomness it may be some WiFi operation that does this. With WiFi off I of coarse do not see these drops in voltage and thus I have never known loop() to stop.

I tried the same operation on a Photon and I can not reproduce this behavior and I do not see these drops.

The voltage theory is consistent with the datasheet for the CYW43438 radio. The internal buck boost reg has a min voltage of 2.4. If the reg becomes unstable then components downstream would as well. Perhaps the Duo needs more capacitance on the LDO reg’s output by default? These are “stock” Duo boards I am using.

Drop22


#6

So if the Duos those rarely exhibit this issue has the same drop? According to what you described, it might be the problem of non-consistence between components on different Duos. But it’s hard to address the exact issue on firmware or hardware.

FYI, the Wi-Fi chip on Photon differs from the one on the Duo.

Best regards,
guohui


#7

To clarify those Duos that show the issue less frequently just seem to be less prone to such an extreme drop in voltage. If I force the drop below that ~2.2V threshold they too will glitch and loop() stops.

Right, different hardware on the Photon, it was more of a check on the firmware. In any case this seems to be an issue unique to the Duo.


#8

What if you do not publish data to MQTT server? Will the voltage drop occure?


#9

If I am not publishing data then no, the drops do not occur. The radio activity is obviously part of the equation here.

The caps I added have addressed the issue for now. Perhaps I have some faulty components on these boards.

-AP


#10

Hi @panda would you mind send me your sketch for testing purpose to target the problem? I wonder if this drop occurs for several times before reset or just one time, so I might know the action that to the Wi-Fi chip consume such huge power suddenly.

Best regards,
guohui


#11

I will do my best. I will likely have to pair it down, but I will try.

-AP


#12

Having the same issue. I’m sending 16 bytes packet through UDP every 75 milliseconds. The transmission stops randomly and starts after a few seconds.

@panda The bypass capacitor is between Vin and GND right?


#13

Yea, that is the idea. In my case Loop() was permanently disabled and required a reboot. Perhaps in your case there is some blocking function. Are you using SYSTEM_MODE semi-auto? Manual?


#14

Sorry for the delay.I was trying out an alternative through ethernet adapter module but the speed didn’t suit my purpose

@panda Right now I’m using Manual mode.But I have used both modes in two different Duo boards.The issue seems to really random now. I ran it for continuous 24 hours now and I am capturing the data sent by Duo board at rate of 40 16 bytes packet per second.

Sometimes the loop is blocked for minutes together sometimes for few hundred milliseconds.When I used the board with capacitor the loop is blocked only for few hundred milliseconds