Hello,
I´m using the Arduino Mega2560 Board, with the 10DOF Sensor SEN0140 and the GPS Modul "Ultimate GPS Breakout V3" by Adafruit.
When I read out the ACC and the GYRO values in a loop over I2C, first it seems to run proper.
My problem is, that my routine(see below) always freezes after a while when the RX, TX pin from the GPS modul is connected to the hardware serial port.
The controller hangs up after a non deterministic time. It take about 10 seconds to several minutes until it happens.
If anyone had the same or a similar problem let me know. I don´t have no more ideas what reason this issue might cause.
My problem is, that my routine(see below) always freezes after a while when the RX, TX pin from the GPS modul is connected to the hardware serial port.
To which hardware serial port (the Mega2560 has 4 of them)?
If you don't connect the RX/TX lines but leave the GPS powered does your sketch run then without problems for a long time?
@ pylon: I already tried all of the for four serial interfaces. It causes always the same issue. When I leave the GPS powered, without connecting RX, TX it runs stabil. The GPS Module has a power consumption of 37mA with a fix. The IMU takes 13 mA while using it.
@robtillaart: u are right. I fixed it. Unfortunately I´ve still the same problem.
It seems that I cannot use two different Interfaces (I2C and UART) at the same time.
It seems that I cannot use two different Interfaces (I2C and UART) at the same time
Believe me, you can. In your sketch you don't use the serial interface, so it seems to be a problem of connecting the GPS to the Arduino. As you don't have any code in the sketch really accessing the GPS, it doesn't seem to be software related.
Replace that part:
Wire.beginTransmission(DEVICE); // Übertragung starten
Wire.requestFrom(DEVICE, num); // num Bytes von Zieladresse anforden
int i = 0;
while(Wire.available()) // checken, ob auch Daten bereitliegen
{
buff[i] = Wire.read(); // byte empfangen
i++;
}
Wire.endTransmission(); // Übertragung beenden
with
if (Wire.requestFrom(DEVICE, num) != num) {
return; // read failed
}
int i;
for (i = 0; i < num; i++) {
buff[i] = Wire.read();
}
The Wire.beginTransmission() and Wire.endTransmission() are not necessary and wrong here. The while loop doesn't check for more data than requested (shouldn't happen but if it happen, you have a buffer overrun).
Thank you pylon for your effort, ...
I replaced the code as you proposed...but it is still freezing after a while.
I now remarked, that I had internal pull-ups enabled and also used external 10K pull-ups. I have now disabled the internal pull-ups, but still the same problem....enabled internal pull-ups, using external pull-ups, still nothing changed. Could it be possible, that the usage of a breadboard with its suboptimal electrical connections causes a bus breakdown? I tried out another breadboard, and now it is freezing a lot earlier than before. I added a picture of my hardware composition. Perhaps it helps to find a possible error.
I feel like I don't see the elephant in the room
Normally it shouldn´t be no problem reading the two serial interfaces.
I really need help with that. It is part of my bachelor thesis and I need to get this done!
Do you have some code which reads these two serial interfaces, so I could compare line by line?
You didn't mention the WiFi shield before, did you?
Have you tried powering your setup from an external power supply? In this constellation it might be possible that the power supply from the USB might not be appropriate.
I now remarked, that I had internal pull-ups enabled and also used external 10K pull-ups.
10k are usually too weak. Use 4k7 or 3k3 instead.
Do you have some code which reads these two serial interfaces, so I could compare line by line?
I have no code driving exactly that setup and posting code driving some other setup won't help you here.
Post your current code, perhaps we find some other problem.
I didn´t try an external power supply yet. But I will do, even if I do not belive that it will help. The USB port is giving me 500 mA. Am I right there?
But either way it doesn´t run with or without the WiFi shield.
I tried the 4.7K resistors, unfortunately no improvement.
What I actually want to do, is to read out IMU data as fast as I can. At the same time, I want to read out GPS data in a 5Hz cycle. These data should be written to SD card and be sent by WiFi.
The code I posted few days ago is simplified, because I first thought I have conflicts with the used libraries. So I wrote this simplified code, where I´m just using the wire.h librarie.
The code I added below, is the older version which first seems to work, until I remarked that it is freezing after a while.
Thank you so much for helping me with that curious problem...
When running that code and it stops, does the LED stop blinking too? Have you tried moving the digitalWrite() for the LED into the ISR? Does that change anything?
To do stuff in a single digit Hertz frequency you don't need a timer interrupt, just use millis() and divide accordingly.
I would comment out the speed increase to 400kHz for the TWI while this issue persists. You can re-enable it when this is fixed. It's a possible source of problems and therefore I would try to eliminate it.
boolean i = HIGH;
You have this global variable and in the subroutine of the GPS reader you use a variable of the same name again for iterate over a serial reading block. Try to avoid such name clashes.
Yes, when the code stops, the LED stops blinking too.
To do stuff in a single digit Hertz frequency you don't need a timer interrupt, just use millis() and divide accordingly.
I prefer using the timer interrupt, because it makes me more flexible. Should work though.
You have this global variable and in the subroutine of the GPS reader you use a variable of the same name again for iterate over a serial reading block. Try to avoid such name clashes.
I´ve changed this too. But no improvement.
I will now disable I2C fastmode and tell you tomorow if this changed something.
Other question: You are from Switzerland. Do you speak german too?
Have you tried moving the digitalWrite() for the LED into the ISR? Does that change anything?
Have you done that too? If the LED still blinks then but the Arduino stops responding we at least know that the program is still running and it gives us hints where to look for the endless loop.
Other question: You are from Switzerland. Do you speak german too?
Yes, I do, but you posted your question in the English part of the forum.
Yes, I do, but you posted your question in the English part of the forum.
...so lets go on in English. It should be a good practice for me.
Have you tried moving the digitalWrite() for the LED into the ISR? Does that change anything?
You were right. If I move digitalWrite() to the ISR it continous blinking, although the serial communication via HardwareSerial0 (USB) stops. So now we know, that the program is still running. Hmmm... For me it seems, that the I2C is hanging up. But I really don´t know why. In the meantime I also remarked, that I can force this freeze, which actually isn´t a freeze, by turning on my china made switch-mode power supply. Accordingly, the I2C bus is reacting sensitively to EMP.
I measured the I2C and HardwareSerial bus signals with an Oscilloscope. The GPS module keeps sending data to the RX pin of the Mega2560. On the TX pin of Mega2560 I have a flat-line, which is not surprising to me. The I2C has flat-lines on SDA and SCL after the freeze. Neither clock nor data signal. This is surprising me though. I expected a least a clock signal.
I wrote, that due to a glitch, the I2C bus can fall to a state called "arbitration lost". When this happens, I2C slaves waits for data and hangs until the next reset. They propose to use SW-I2C to force a STOP by the 9th tact, when I2C hangs up.
I still don´t understand the interdependency between the I2C breakdown and the connected UART interface. Because still, when UART is just not connected, I2C runs and runs...
Do you have any idea?
I think I found the solution. As you can see on the photo above, I used unscreened wires in comparison with the Breadboard. I2C is definitely very sensitive against EMP, which causes the bus freezes. I now use screened wires and don´t use the Breadboard anymore. The issue now occurs very rarely.
Unfortunately I still don´t understand the interdependency to the UART interface. I will now improve the screening of my wireing. Hopefully, the breakdowns will totaly diappear.
Summary:
My final solution, after weeks of detective work is, to use another sensor board.
Obviously the ADXL 345 together with connected UART, provoked by EMP is the problem. I still don´t know why, but now, using the 10DOF GY-86 board with the MCU5060 IMU, it runs stable in a longtime test, for over 60 hours! No more freeze!!!
I hope this will help someone having similar problems!
