Hello, I have two (hopefully) identical Arduino Nano with Atmel ATMEGA 328p, with 16 MHz crystal. The same program works in one of them but does not in the other one. I reduced my program to a simple serial echo sketch at 1200 Bd. i.e. any character received is sent back.
In both boards the serial port reacts, i.e. receives serial data and sends them back. However, one works correctly at 1200 Bd while the other one seems to be set to an unknown baud rate.
When I modified my sketch to read UBRR value, switch to 19k2 (which always works fine), it reported UBRR value found when 1200 Bd was set, as 1666. This would be OK for 600 Bd, or for 1200 Bd with double-rate sampling.
I was unable to find reason for such behavior. Same hardware, same program, and yet, different results. I was trying to run terminal on half or double the speed. I also changed serial baud rate in the program, but none of that fixed the problem.
Where could I look for further information? What else could possibly fix the problem?
Did the faulty board run well before ?
If they are official Arduino boards and you never have changes the fuses, then they should do the same. If a board is from AliExpress/Ebay/Amazon, then anything is possible. It might even be a fake microcontroller.
The clock could be set to the internal 8MHz oscillator. There is a online fuse calculator that shows the fuses: AVR® Fuse Calculator – The Engbedded Blog
Are you sure that it has a 16MHz crystal ? Some are sold with a 8MHz crystal.
Can you upload a sketch to both ?
You could try to upload a sketch that blinks a led every second and then compare it with a watch.
My advice: buy a new one, and while doing that, also buy a Raspberry Pi Pico.
Check if your suspected NANO works with Serial Monitor at 1200 Bd.
I am confused! The nano has ONE serial port and that is dedicated to the USB connection to your PC. It is ok to use that serial port, pins 0 and 1, but you then have no connection to the IDE monitor on your pc. How do you know the data being sent is wrong?
Hello guys,
thank you for your ideas and let me answer all points at once.
- Paul_KD7HB: yes, this is the port on the USB (what else, actually...). How do I know data is wrong? a) when I upload my keyer sketch (which works with LGT as well as the other AVR), it does not transmit the expected morse code. E.g. after a row of four A's AAAA it sends Q. The keyer should also echo received ASCII characters, but it sends out garbage. b) when I upload echo sketch (send back to port whatever is received), it also replies with garbage, so the baud rate obviously does not match the expected 1200 (but it seems not to match 600 or 2400 either).
- GolamMostafa: this is exactly what I do - watch the response in serial monitor (I even change baud rate and it does not help).
- Koepel: it does run on 16 MHz because the compiler assumes F_CPU = 16000000 and at the same time the timing matches (for instance tone( pin, hz ) produces the correct audio frequency, not half, nor double as it would be if the clock were running on frequency different from 16 MHz.
Echo sketch:
setup() { Serial.begin(1200); }
loop() {
if( Serial.available() ) {
char c = Serial.read(); Serial.write(c);
}
}
Did the faulty one run correctly before? I don't know actually. Having two boards with AVR and two with LGT I tried all of them as I was developing the software project. Only when the implementation included serial communication, which was milestone 6 IIRC, I noticed the problem.
P.S. the hardware PCB is not designed for Pico, it is designed for Arduino Nano, so at this moment in development Pico is not an option.
So the ATmega328P seems to run happily at 16MHz, not aware of any problem.
The usb-serial chip might have firmware as well. Maybe that chip is bad.
Something seems to be broken. If you visually check the board and it seems okay, then it might not be possible to repair it.
I assume that you tried an other USB cable and an other USB port.
[EDIT] After reading this topic once more, I understand now that this post does not make sense. I'm too confused to understand what is going on.
Can you inpoint if it's the AVR or the LGT boards that pose the problem? Or is it on all of them. Which board package do you use for the LGTs?
The compiler uses what it's told to use; it does not assume 
That's not the point... Compiler is told to use 16 MHz as clock frequency, Arduino functions calculate everything as if clock was indeed 16 MHz and the output frequency is CORRECT => hence, the clock really runs at 16 MHz. This was my answer to comment that the clock could be 8 MHz instead of 16 MHz. Which, anyway, is not the case because serial port runs correctly at speeds 4800 and above (= divider is < 256 and therefore fits into one byte).
TL;DR I decided to throw the board away.
I suspect it might be some kind of fake chip. Something that does not use UBRRH register to control USART speed. I could check this by uploading the echo script, assuming that only UBRRL defines the baud rate and try to set the PC serial port to this baud rate to verify my hypothesis.
However, at the current moment, I am not going to waste any more time on the faulty board and will concentrate on my keyer program.
Thanks everyone for help and ideas!
Hi, LGT (at least 3 pieces) = all OK. AVR (2 boards) = one is OK, the other one refuses to communicate at 1200 Bd.
The original issue was "is there anything specific about USART in AVR at low speed that I may have screwed?"
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.