Hi Everyone!
I have been struggling with some noise that is random and affecting the performance of my project.
To give you a summary, I have a total of 5 Nanos and 3 Megas running together on an I2C network and one Mega is connected to a PC with the USB cable to a GUI. It all works together to run a printing press.
Everything runs and works as expected where some Nanos are gathering pulse information for speed of various parts and others are output devices for equipment.
The issue is when you test a single Mega with Blink, there is no issue. Pin 13 blinks. Always.
My sketch, running for days interrupted can die suddenly if you get too close to the Mega.
I removed chunks of the program and feel the issue is related to I2C traffic.
I need the I2C to be there and do have pull up resistors installed.
Why I decided to post this is that I have now tried to add an I2C eeprom and it works on my desk but fails at the equipment.
I am clearly on the edge of something bad.
I have .1uF caps everywhere and ground plane pours on my pcbs..
Any insights to push this back would be wonderful
Here is a link to a YouTube video of the issue. (The direct soldered usb was an effort to eliminate any connection issues. This is a new Mega)
Exactly Southpark!
I am fighting some sort of shadow. The general rule is to backup, check the basics and the issues float up to the top. This always worked in the past.
On this Mega, I have the glove on since I had a fear of grounding or conduction with the Arduino.
I had the same issue with the glove on or off.
I used blink as an example to indicate there is nothing busted. My code has enough I2C running on it all the time, that I believe, between the code doing its work and the wires it needs to work, I have made some sort of noise that cannot be silenced. ..and you can see from just one Mega and the code, we can force a failure with no wires connected to it.
On the back of the Mega, I have the plastic cover on it and it is covered with foil that is grounded. That did not help either way.
Where I am now is I am running a slower program (delays), am flushing serial buffers and adjusted the sketch to reduce the I2C traffic. I have tested different I2C speeds, different baud rates and have added a watchdog (sadly) to keep my environment stable.
This works but there is no headroom here to add that eeprom. I am back in an eeratic state.
I feel there is something I have missed, or some golden rule I have broken but for the life of me, I can't see it.
Adding: I tried to duplicate this very issue with a different Mega on a different desk and it was better. Having said that, the environment (humidity) was also different (the video is a bit more than a month old). I removed the back plastic cover and came closer to the Serial1 and the I2C pins and it was fatal.
I am going to break out the scope tomorrow and see what sort of dirt there is on those waves.
Gary -----the first thing to establish right now is ----- what happens when you use a typical USB cable connected to the MEGA2560 in the usual way?
That is - if the MEGA2560 is running the basic blink code only --- ie. no i2c communications etc --- just blink code and general USB cable between computer and arduino ...... what happens when you put your hand close to arduino in the way you did? Any lock-up/freezing?
I've loaded the basic blink code into a MEGA2560 and the LED keeps blinking - no problem - no glitching/freezing when I put my hand and fingers real close to the arduino ----- with hand and fingers really close to all sections on the top side of the board.
karnak:
I tried to duplicate this very issue with a different Mega on a different desk and it was better.
What do you mean by 'it was better'? Did that different MEGA freeze too? Did you manage to duplicate the issue with that different MEGA? And for this different MEGA, were you using a typical USB cable connection? That is --- regular USB cable, with regular USB connectors.
Thanks for your reply.
I loaded up blink and the Mega was solid. I could not get it to stop blinking..even by touching the pins.
When I tried to duplicate the issue yesterday, I had to go back into my past sketch revisions and find a sketch from the era of the video I took. Since the result I had back then was so undesirable, I had altered the sketch and not saved that exact version. My heartbeat (pin 13) was a quicker blink in the video than I had yesterday.
Still, the sketch I ran yesterday failed but not as readily. The amount of static in the air / on me / on the desk, I suspect is less now. My issues started in the fall and ironically they are not as bad now (until I added the eeprom).
The I2C pins seem to be the weak link. I think the environment (me / the weather) is helping to degrade their function to the point where the sketch stalls.
In the machine, and not on my desk, I have the addition of electrical motors and high voltage wires that make matters worse.
The desk test was in part, some way of demonstrating how electrically fragile the Mega is. At this point, I can't be sure that all the little adjustments I have made are the improving the stability or if the weather has more to do with it.
Gary..... if you have or are able to find the blink code that reproduced the issue consistently - and able to share that particular code ...... then that might help somebody here to home in on the issue. Your video showed a bare arduino running a blink code .... but no-one knows what other code was being run in that demonstration as well.
It's good that you've established that no issues arise when regular blink code is running in a bare mega. That gives good information.
Hi MarshaJ847!
The wiring is done via direct pcb header ot thru a short patch cable, Cat 6 with shielded ends. In an earlier version I had used USB cables and found out that the I2C signal degraded rapidly.
(apologies for the links..the preview would not load my images)
Here is the I2C running with nothing..no pull up resistors..just a bare Mega
I had whipped up this I2C buffer board. It uses the TCA4311A hot swappable buffer chip and it does a nice job of keeping the master isolated.
The waves don't look too different though.. a little sharper...
...another looks with a 2 volt scale.
The sketch is quite large and I may be able to post a fragment of it that presents a challenge. I believe it is not the code so much as the use of Serial1 and I2c and the serial.print (for PC communication) all together. I had pondered that I had run out of memory but have not found any real evidence of it.
Thanks!
Just adding to this post.. The eeprom I have spoke of that works at my desk (very well) but runs like a bag of poop on the machine exhibit nearly the identical I2C wave (more links to pictures) have me a bit concerned that I may have more than one issue. I am going to attempt to sharpen my signal. I have 3.3k pull up resistors installed at the moment.
(If I dive into sketch related concerns, I will post under a different topic.)
Ok.. Here is what I found..
The eeprom that I was trying to use was the main issue and not the wires.
It had A0, A1, and A2 set low for addressing. A hex 0x50. ..and one of my many nano slave devices was address (80). I had a conflict.
I set A0 to high on the eeprom to make it 0x51, or 81 and my I2C network was stable.
The static and other electrical issues may again return, but for now, I am going to take the win and run.. lol
