<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>On 01/22/2017 03:37 PM, Chip McClelland via TriEmbed wrote:<br>
</p>
<blockquote
cite="mid:DEFA4CFF-302B-4A89-ABFE-AAB275FF1176@mcclellands.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>-
When I do get the system to lock up, his is what I see:</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>-
The Arduino is the one that is locked up not the Simblee</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>-
When the Arduino locks up, the Simblee is unable to take control
of the i2c bus</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>-
The Arduino is in the “sleep” state and will not wake up - with
the pin change interrupt set and <u class="">even if I manually
bring the interrupt pin low</u></div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>-
The Arduino will not reset <u class="">even if I manually bring
the reset pin low</u> - this is odd and what I have come to
call the "fugue state".</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>-
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)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>-
The only way to recover is to power cycle the device</div>
<br>
</blockquote>
(Since your board is full custom and doesn't look like an Arduino,
I'm going to just refer to the IC.)<br>
<br>
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".<br>
<br>
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. <br>
<br>
-Pete<br>
</body>
</html>