Hi,
I'm creating a rfid 13.56MHz reader using an arduino. For this purpose I'm using a i2c chip from ST to do all the rf stuff and I simply use the i2c protocol to control it.
I'm getting weird behaviour from my Arduino UNO. It seems to stop working "randomly". I mean, I'm in a loop with Serial.print() all over the places and also pin13 led blinking and then, suddenly, it stops. 5V are still getting to the AVR because I checked that out manually.
I'm also getting strange behaviour from i2c... It works for a while, then it stops working and the only way to restore it (and it doesn't even work every time) is to disconnect/reconnect the USB cable.
I've only 4 cables attached to arduino: 5V/GND to power my PCB (it's like 6 capacitors and the IC, the PCB is taken directly from the IC datasheet) and SDA/SCL. I tried i2c both with internal and external (4K7) resistors.
Another weird thing is that, while doing all this reset-recconect usb-reset... etc, sometimes the circuit/software suddenly works like a charm and then it continues to work. In other words, I don't get the behaviour mentioned above anymore. And after a reset, or when I remove the rfid TAG from the antenna, it stops to work.
It all seems to happen randomly maybe a fucked up arduino?
I checked my PCB for short-circuits but I can't seem to be able to find it. I also checked current drain from 5V to GND and it seems to be all OK
Please guys, help me shed some light on this issue.
3mpty
This is my loop(), the function I call are only simple i2c writing/reading stuff. And they work because, when I'm lucky and all goes right, the program does some write/read back tests.
tuxduino:
You're right, not enough strings to fill SRAM.
setup() is missing.
Please consider posting here the code, using the # button.
This looks strange to me, especially since it's inside loop():
//Setup serial
Serial.end();
delay(100);
Serial.begin(9600);
I didn't post the entire code since I'm doing some security hacking stuff
The Setup is just something like Wire.begin(); Serial.begin();
The code you quoted was added by me for testing purpose, it doesn't influence the problem, I added it later.
Whenever these two lines are reached:
while (1)
delay(1000);
the program will "stop", i.e. it'll keep delay()ing for the rest of time...
Finally, give a proper indentation to your code by hitting CTRL-T.
Yeah the fact is the excecution stops without reaching that point
The only "strange" things I see in the code you posted are the ones I mentioned earlier. I can't see how one can help you diagnose a problem if you don't post the full code, or at least a simple(r) sketch that shows the bug.
Yeah the fact is the execution stops without reaching that point
Yeah I know that without posting the code it's difficult to help me... but I'm almost sure it's a hardware problem. It would be really helpful to know under what circumstances the avr would stop executing the program or "forget" the sketch uploaded to it.
It stops mainly during the first i2c-related calls (beginTransmission(), endTransmission())... But, really, the software should be correct because, as I mentioned earlier, I got it working from the beginning to the end a lot of times.
Sorry if I sound a bit scumbaggish it's just that I spent something like 2 days trying to solve this problem and it's not like it's the first time I write some code. Thank you for spending your time reading my rants
So, to get to the point, I would really like to know if someone knows what kind of hardware failure can cause the AVR to stop working (or executing an infinite loop of NOPs for that matter... the result is the same: it's dead).
If I manage to, I could try to execute my sketch on a friend's arduino to be sure it's not the problem.
If the I2C communication is interrupted, the Arduino will busywait indefinitely for an ack that never comes, which sounds like your problem--make sure that the connections are secure.
Aeturnalus:
If the I2C communication is interrupted, the Arduino will busywait indefinitely for an ack that never comes, which sounds like your problem--make sure that the connections are secure.
That's a quite interesting information. Today I already made the connections more secure by using strips and soldering everything. It seems little to nothing changed.
But now that you say that Arduino busywaits for an ack indefinitely, plus the fixes I made to the connections, make me wonder if the problem lies in the i2c part of the PCB. It would definitely be strange since it's like a copy/paste circuit from the IC manufacturer's datasheet, but who knows.
The only other option, excluding Arduino from being the source of the problems, is that the IC was damaged (during soldering or tests).
Tomorrow I'll investigate,
it's 2 am and I need some sleep
Thank you guys
So guys I finally got some results from attaching a scope to SDA and SCL lines.
I have 3 cases:
The i2c tests fail due to lack of Ack bit. In this case the sketch continues to run. From the IC datasheet I read that Ack bit missing could be due to a wrong i2c address being received by the IC. It's rather strange this happens this often, though.
I get an infinite clock pulse from SCL while SDA is at GND level. This causes arduino to "freeze"... I think this happens when something goes wrong while trying to read something from the IC. Arduino stick in reading mode since it never reaches the No-ACK (meaning end of data) due to SDA being low.
SCL is constantly at Vcc (5V) and SCL is at GND. I don't have a single clue about this one. SCL being always at Vcc means that something is wrong with arduino, since it is the bus master.
All of this point me to thinking something is definitely wrong with arduino, because in the first 2 cases the problem could be due to either the IC or arduino, while in the 3rd it should be all arduino's fault.
Maybe I am missing something? If someone has a theory to explain the 3rd case it would be awesome, since it's the only one indicating a problem arduino-side.
If your code with super secret stuff won't work, I'm pretty sure it isn't the hardware that millions of people (arduino is close to 1 million official boards, not counting clones, and not counting on-arduino AVR) are using with the issue.
3mpty:
I get an infinite clock pulse from SCL while SDA is at GND level. This causes arduino to "freeze"... I think this happens when something goes wrong while trying to read something from the IC. Arduino stick in reading mode since it never reaches the No-ACK (meaning end of data) due to SDA being low.
SCL is constantly at Vcc (5V) and SCL is at GND. I don't have a single clue about this one. SCL being always at Vcc means that something is wrong with arduino, since it is the bus master.
I just worked through a very similar problem. In my case, after NACK, the Arduino master was unable to generate a stop. This caused the I2C bus to crap out, and it locked up the Uno. Your situation sounds really similar.
Turned out that the successful solution for me was a software revision on the slave side. The slave was not always releasing SDA. Once in a while it was holding SDA low after NACK, making it impossible for the stop to be generated.
I'm not saying there's a problem in arduino per se, I could have ruined it with past circuits... who knows. My code works, since I can read the hell out of my rfid tag, it's just that when I power arduino+pcb it works only, say, 1 time out of 5. But once it starts the right way, it continues to run until i reset the board or disconnect the usb cable. I also checked with a scope.
It could also be the pcb's fault, it is just strange I get SDA at GND and no clock on SCL. That's what I'm trying to figure out.
florinc:
All of this point me to thinking something is definitely wrong with arduino
Did you try changing the ATmega328 in your Arduino and seen if the new one works?
There aren't so many things on arduino that can go "wrong".
I don't have a spare ATmega328 But yeah, I could have fried it... It's one of the thing I thought of.
JimG:
3mpty:
I get an infinite clock pulse from SCL while SDA is at GND level. This causes arduino to "freeze"... I think this happens when something goes wrong while trying to read something from the IC. Arduino stick in reading mode since it never reaches the No-ACK (meaning end of data) due to SDA being low.
SCL is constantly at Vcc (5V) and SCL is at GND. I don't have a single clue about this one. SCL being always at Vcc means that something is wrong with arduino, since it is the bus master.
I just worked through a very similar problem. In my case, after NACK, the Arduino master was unable to generate a stop. This caused the I2C bus to crap out, and it locked up the Uno. Your situation sounds really similar.
Turned out that the successful solution for me was a software revision on the slave side. The slave was not always releasing SDA. Once in a while it was holding SDA low after NACK, making it impossible for the stop to be generated.
Jim
Slave side I have only an IC A swap of the ATmega would definitely give me an anwser to my problems, hope to get my hands on one soon.
Btw, the i2c read should definitely have some kind of watchdog/timeout built-in IMHO.
One of the principles in debugging is to simplify the code as much as you can to the point that the problem still shows up with the least amount of code.
Take out you security (secret) code and see if the problem still shows. If that's the case, you should be able to post your code at this point.
florinc:
One of the principles in debugging is to simplify the code as much as you can to the point that the problem still shows up with the least amount of code.
Take out you security (secret) code and see if the problem still shows. If that's the case, you should be able to post your code at this point.
I second this suggestion. But I'd go even further and write a sketch which would only test the I2C communication...
I swapped the IC with a brand new one... nothing changed.
I swapped Arduino with an Adweeny... nothing changed.
I swapped both of the... nothing changed.
Then, just for the sake of doing it, I replaced the quartz with a brand new one. Identical. Same batch.
Guess what? Now it seems to work fine
Could someone explain this to a software guy?
Btw, thank you very much for your help men, Arduino has a great community.
I guess one reason is that if the quartz resonant frequency is too far off the nominal one, then all the timings based on uP clock frequency become wrong, because suddenly 100 instructions do not execute in 100us but (e.g.) in 110us. Small timing errors quickly add up... Also, if a bad-quartz device talks with a good-quartz one I think the signals quickly go out-of-sync. * tuxduino now waits for hw-guys to provide more in-depth explanations
maybe a fucked up arduino?
But yeah, I could have fried it... It's one of the thing I thought of.