0
\$\begingroup\$

I'm sending data from an ATMEGA 328 to a PC and I have an incrementing line counter for each block of data I send. (4 integers)

When I start and stop the receiving program on the PC, it resets the count in the ATMEGA. Why?

What I have noticed is that the transmit light continuously flicks when sending data (PC receiving data or not) and once I start my receiving program on the PC, it stops momentary like it is being reset and then carries on sending however my line counter is now reset to 0.

It looks like the PC is sending a request to send or something like that and this is resetting the program. Any suggestions?

Thanks Wallace.

Improve this question
\$\endgroup\$
3
  • 1
    \$\begingroup\$ If you run on Arduino compatible platform, a handshake pin will reset the AVR if the serial port opening on PC toggles it. But you don't give almost any info like AVR or PC program or about the schematics. \$\endgroup\$ – Justme Feb 23 at 22:08
  • \$\begingroup\$ Also check that the reset pin (PC6) is connected to VCC, say through a 5k resistor. There could be interference. \$\endgroup\$ – blaber Feb 23 at 23:33
  • 2
    \$\begingroup\$ Add information about the development board you are using. Your description makes it sound something like an Arduino Uno, but maybe it's something older like the Duemilanove. The newer Uno's have a MEGA16U2 as the USB controller and the Duemilanove has the FT232. The Uno has a reset jumper pad that you can cut but I don't think this was on the Duemilanove, so you have to physically remove a capacitor of find a suitable place to cut the PCB trace. So you see, board flavor changes the answer. \$\endgroup\$ – ScienceGeyser Feb 24 at 1:32
0
\$\begingroup\$

Am I to understand that you are not using the Arduino IDE's Serial Monitor to display your data? In which case I would have to assume that you're using another IDE or program, or you're building your own software to interface with your Arduino ATMEGA328 hardware. I'm not sure I understand. Can you be more precise? Which program are you using as the "receiving program" if it's not the Arduino IDE?

It sounds like you're using a loop structure to increment a (4-digit) line number as your computer receives the data. The Arduino UNO, Nano, and MEGA2560 use the ATMEGA328 if I'm not mistaken. I know for fact the UNO uses digital pins 0 and 1 to send and receive data. I don't know if you have anything connected to these pins that could be causing a problem, but it is normal for the RX and TX LEDs to flicker as data is being sent or transmitted (TX), and when data is being received (RX). On the MEGA2560, communication pins are used for transmitting and receiving data on pins 14-19 (TX1, RX1, TX2, RX2, TX3, and RX3). The LEDs work the same as on the UNO, and should flicker when the board sends or receives data. With what little info you gave, I suspect that you have a coding problem, but without any code I can not verify this. However, I strongly believe that your board is working properly. However, these pins should not affect your counter. If you have anything connected to RX or TX on any of the three microcontroller boards, try connecting these to other digital pins, and see if this solves the problem. Don't forget to change your code to include the new pins.

Improve this answer
\$\endgroup\$
1
  • \$\begingroup\$ I'm using 3 x ADC inputs (5 ,6,7) PB0 as the pulse input and INT0. Nothing else is connected. Sending at 57600. \$\endgroup\$ – marsheng Feb 24 at 8:51
0
\$\begingroup\$

Ok, so you're using a Nano, which you've programmed with AVRstudio4 and the ISP instead of Arduino IDE, and you're monitoring the results with Realterm. A quick look on Google tells me these programs are outdated. I imagine AVR Studio 4 is similar to Arduino IDE, except it seems to have debugging features lacking in the Arduino IDE. To be honest, I am completely unfamiliar with the ISP aspect of your programs. And, I'll take it for granted that Realterm is similar to Arduino's Serial Monitor.

This is what I understand so far. Your data line contains a line counter, timer value1, timer value2, ADC1, ADC2. So that, the periods in your sample are the delimiters, and the first data line represents the following:

327 = Line counter 0 = timer value1 0 = timer value2 35 = ADC1 58 = ADC2

In your first sample:

327.0.0.35.58. <- this line would seem to be processing correctly :328.0.0.35.55. <- so that this line is processed correctly :329.59304.0.37.5šù <- then, what is causing this "šù" garbage? This must be where your counter resets. :0.0.0.35.58. <- it affects all of your following data lines :1.57331.0.35.56. <- this line would be processing correctly if "šù" problem is solved :2.56494.0.36.57. <- this line would be processing correctly if "šù" problem is solved :3.55558.0.34.57. <- this line would be processing correctly if "šù" problem is solved :4.54761.0.34.57. <- this line would be processing correctly if "šù" problem is solved :5.54018.0.35.57 <- this line would be processing correctly if "šù" problem is solved

Then again a bit later.

:291.0.0.37.57. <- this line is processed correctly :292.0.0.37.58. <- this line is processed correctly :293.58583.0.36.µþ <- again, what is this "µþ" garbage? This must be where your counter resets. :0.0.0.36.57. <- it affects all of your following data lines :1.56855.0.36.58. <- this line would be processing correctly if "µþ" problem is solved :2.55898.0.36.57. <- this line would be processing correctly if "µþ" problem is solved

If I am not mistaken in interpreting your data line, the problem seems to occur when your code reaches ADC2 variable for a 3rd time. The problem is either occuring in a consistent or inconsistent manner. If these samples you provided are only fragments of the results obtained during program run, then the problem is likely occuring inconsistently; or, if you have provided these samples from the start of the program run, then the problem occurs consistently after a 3rd loop structure begins in your code. Could the answer be that one of your programs (AVR Studio 4 or ISP?) is not initalizing the ADC2 variable properly or in the correct sequence before new data is added, and this is causing the problem; or, one of your programs is adding uninitialized data from another variable to the ADC2 variable, and it contains garbage because that variable wasn't initialized in your code.

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

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.

:327.0.0.35.58. :328.0.0.35.55. :329.59304.0.37.5šù:0.0.0.35.58. :1.57331.0.35.56. :2.56494.0.36.57. :3.55558.0.34.57. :4.54761.0.34.57. :5.54018.0.35.57.

Then again a bit later.

:291.0.0.37.57. :292.0.0.37.58. :293.58583.0.36.µþ:0.0.0.36.57. :1.56855.0.36.58. :2.55898.0.36.57.

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 '?'

ISR(BADISR_vect)

{

send_byte('?');

}

So I'm getting an ISR in the send routine. Here is my new data.

I'm getting a ? after the block.

:602.0.0.31.52. :603.58485.0.30.52.? :604.0.0.33.50. :605.55807.0.31.52.

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.

Improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.