[TriEmbed] Suggestions Needed to Improve Quality / Reliability

[Pete Soper]

On 01/22/2017 03:37 PM, Chip McClelland via TriEmbed wrote:

> - When I do get the system to lock up, his is what I see:
> - The Arduino is the one that is locked up not the Simblee
> - When the Arduino locks up, the Simblee is unable to take control of 
> the i2c bus
> - The Arduino is in the “sleep” state and will not wake up - with the 
> pin change interrupt set and _even if I manually bring the interrupt 
> pin low_
> - The Arduino will not reset _even if I manually bring the reset pin 
> low_ - this is odd and what I have come to call the "fugue state".
> - The Simblee will be visible on Bluetooth LE but will lock up when I 
> attempt to connect and it tries to read the i2c bus (I do not have a 
> timeout on taking the bus)
> - The only way to recover is to power cycle the device
>
(Since your board is full custom and doesn't look like an Arduino, I'm 
going to just refer to the IC.)

Well, the Atmega not doing the right thing in response to the reset pin 
being pulled down seems like the smoking gun. This is of course 
"impossible", so the question is how this could be happening. The only 
two things I can think of are a too short reset sequence and an 
intermittent power supply problem. Is the Simblee holding the reset line 
low for at least 2.5 microseconds? The rest of this assumes "yes".

What's the clock speed of the Atmega? What's the Atmega's supply voltage 
when it won't respond to reset? Will the Simblee run with a lower supply 
voltage than the Atmega? I wonder if the fugue state is to do with the 
onboard DC to DC converter vs the Atmega. If you could watch and record 
the Atmega's VCC pin while trying to reset it out of the fugue state you 
might see it sagging as the Atmega tries to start up: the Simblee is 
able to keep running (or the sag might be causing the Simblee to stop 
and restart. Can you detect that?). Is there any correlation with 
temperature or battery state? Can the Atmega get it's work done at a 
lower clock speed? Purely as an experiment you might lower the speed to 
reduce its power requirement. If it rides through and "outlasts" all the 
other units in the park, then it might suggest a power supply stability 
issue. Systematically testing the power supply might be in order.

-Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20170123/f274ffc7/attachment.htm>