I have a little application I’m developing that basically reads some digital inputs, then displays a figure on the little RGB TFT display, before a short delay and looping round again.
Each set of reads and the associated display is a single iteration of the loop() routine, so in theory, should just keep going around and around.
However, I have found that it stops looping during the second iteration. If I remove all the tft operations, it runs as expected, but as soon as I reintroduce the tft commands, it dies during round 2.
After endless tinkering with the code, I decided to swap out the Nano itself and replace it with another (they are both cheapo clones and were bought at the same time from the same supplier), and guess what - it worked perfectly. I put the first one back, just in case… but the original issue came back.
There’s obviously a fault on the board itself, and at just a few bucks, it’s easier to simply replace it, but I’m wondering if there’s a way to diagnose the issue, and if it is likely to be a memory issue…
Any thoughts?
Yeah, maybe.
Need a better answer? Ask a better question. Read the forum guide in the sticky post at the top of most forum sections for advice on what the forum will need in order to be able to help you.
Apologies - the Nanos are simply cheap eBay Nano compatible clones - there are no labels or identifying marks on them, other than pin out labels.
The TFT mentioned is again a cheapy from eBay - a 0.96” 80x160 RGB IPS display, that I am driving using the Adafruit ST7735 and GFX libraries.
I could include my code but if it works on one Nano but not another when it is a straight swap with no other wiring, components, or code changed, then the issue is proven to be a hardware (or maybe firmware) issue on the board.
I’m not expecting anyone to come up with an actual fault, but would appreciate guidance on how to potentially troubleshoot the board further, unless there is simply no point.
But there are many types of Nano these days, with different chips and capabilities. Which type are they clones of?
Assuming they are the most common, classic "V3", it's possible that one of your clones has the usual ATMEGA328 chip but the other has the ATMEGA168, which has half as much memory, and was used in older versions of classic Nanos.
But even if that's the case, there's nothing you can do to fix it, except replace it.
If you can read the printing on the chips, and you have been sold one ATMEGA328 and one ATMEGA168, then you could try to return them for refund or request a partial refund or replacement.
EDIT: if my ATMEGA168 theory is correct, the IDE would fail to upload your code until you selected "ATMEGA168" option in the menu, so that's probably not the problem.
Do you have the exact same version of the code on both Nanos, and the compiler did not update any of the libraries or board packages between the time you loaded the sketch on each Nano?
Did you solder headers onto the Nano yourself, or were they pre-assembled? A bad solder connection, or flux residue between pins, could cause problems.
With the cheap boards, its also possible some of the components are very loose tolerance, and the parts on the non-working Nano are just far enough out of spec to cause problems.
This would make me suspicious of the code itself, if the problem always occurs at the second iteration, and never at any other time.
Thanks for the thoughts Paul. The two devices are (to the naked eye) identical, with the same Atmel MEGA328P chips. I suspect they were bought as V3 clones, but it was several years ago now, and I don’t specifically remember - but they are not special variants with Wi-Fi, Bluetooth, or any other gadgets - just plain simple Nano boards.
Hi David - yes, its the exact same code, libraries, etc. loaded on both Nanos, and the issue is not related to my sketch, as it worked perfectly on one Nano and not the other.
I soldered the headers on myself, but dont think that is specifically the issue... however, the fact that this board has been inserted into, and levered out of breadboards many times over the years could have given rise to a weakened dry joint or even a microfracture in the board itself somewhere I guess.
Did not realize you were using a board that was several years old. Its possible one or more of the I/O ports may have been damaged at some point, it would be incredibly lucky if you had never hooked anything up incorrectly over that amount of time.
LOL - very true. I am FAR from immune when it comes to making mistakes… 