I'm using a Nano, programming with AVRstudio4 and the ISP and monitoring with Realterm.
If I disable DTR in RealTerm, the ATMEGA does not get reset on connection. Looks like the DTR resets the comms chip and the ATMEGA.
Something else however, semi random is resetting the program.
Here is sample corrupted data.
:3188.8.131.52.58. :3184.108.40.206.55. :329.59304.0.37.5šù:0.0.0.35.58. :1.573220.127.116.11. :2.56418.104.22.168. :3.55522.214.171.124. :4.547126.96.36.199. :5.54018.0.35.57.
Then again a bit later.
:2188.8.131.52.57. :2184.108.40.206.58. :293.58583.0.36.µþ:0.0.0.36.57. :1.568220.127.116.11. :2.55818.104.22.168.
The data is Line counter, timer value1, Timer value2, ADC1, ADC2.
So my question really is, how can a ATMEGA be reset mid stream? It always resets/faults the program at the end of the send string. I've tried commenting out the ADC conversions and sending 0 but it still faults.
I don't know enough about it, but it looks like a stack fault.
Aha - I found this code for catching missing ISRs and added in the send '?'
So I'm getting an ISR in the send routine. Here is my new data.
I'm getting a ? after the block.
PS The ATMEGA is now not being reset. Now just have to find out what ISR it is. Tomorrows job. It's late here in NZ.
Fixed. I have not enabled ISRs before but needed to to use the hardware interrupt in this case. What I didn't realize that when the counter, on occasion, overflowed, it did not have an ISR routine to go to and crashed the code. This was picked up with ISR(BADISR_vect).
I then made an ISR(TIMER1_OVF_vect) routine that send out a'T' and that confirmed my findings.
So the first reset was by receiving a DTR from the receiving software, (not a train smash) and the second by ensuring any ISR triggered has a valid place to go.
I've really learned something here.
Thanks to all.