This is a question for those only that are part of the community for long enough
AND involved enough to have any significant knowledge about the topic. Don't bother answering
if you are not such a person. Feel free to read the post for the reasons behind this rationelle...
Background:
I am develloping a DC motor driver using an arduino uno as a baseboard with the
(self designed) motor driver board stacked on top of it. The Arduino receives
controll strings of 4 bytes over UART (I will use serial, UART and USART interchangeably knowing that they
are technically different things entirely). For the start I am using the on board USB to serial bridge that
ships with the Arduino (I originally use an Uno board for the real thing but notched up to the Mega2560 for devellopment
for it's JTAG Debugging capabilities, which I have a debugger for (AVR Dragon) instead of the DebugWire of the Uno which I have nothing for) and then later backport the code to the lower-end chip.
How the problem showed itself (Symptoms) and analysis:
Sending Bytes over serial works at any Baudrate. Receiving works technically on every baudrate but echo-ing back the received bytes indicates
something going wrong (still on the Uno, on 115200 baud) no problems show up at 9600 baud however). Switching over to the Mega2560 the problem persists. Some digging with the JTAG debugging later shows
that the Bytes that are seemingly wrong (in the Echo) are actually what the processor received and thus there is no goof-up in the send routine (since the processor transmits to the best of its knowledge) and rather the bytes
are received wrong. Some digging and Logic-analyser-ing later I find that the bytes are send correctly by the on board USB to serial bridge (measuring on the TXD and RXD pins of the Mega2560)
and that the processor seemingly interprets the (single) stop bit as the most significant databit. Leading to the garbage data. Since it is common knowledge that garbage data is usually the
fruit of mismatched baudrates the bit timing is looked at more carefully. Reveiling that the bittiming for the RX data (coming from the onboard bridge) is
a) too fast (several percent)
b) also inconsistent (ranging from 8.3us to 8.7us for 115200 baud)
The Code on the main Processor side is tested and the register contents for the usart are so far consistent and do not change unexpectedly leading to the assumtion that that code is not
at fault. Especially the content of the UBRR0 Register is right ( I tested various baudrates inbetween the 9600 and 115200 marks some especially slower ones work the faster ones dont). The Register contents
are always within +-1 of the recommended setting in the datasheet for the given baudrate for the given crystal (the inaccuracies I suspect come from the Integer division in the UBRR calculating macro, which is a straight copy from the datasheet as well).
Changing the Register to the right value where it is not spot on does help for several baudrates but interrestingly for the 115200 baud the UBRR value is spot on at 0x0008 for a 16MHz crystal as recommended but yielding transmission problems.
Thus the fault is most likely in the atmega16u2 that serves as a bridge for uart to serial. Interrestingly with an external bridge that was specifically designed for that purpose (in my case the CP2102) the effective baudrate for 115200 is marginally slower than it is with the onboard bridge. But everything works just fine.
And indifferent of the baudrate the external bridge yields no transmission problems. Since 115200 is usually not an issue for an arduino even with the onboard bridge i am somewhat wondering what goes wrong inside that poor atmega16 that the baudrates vary so significant.
Also this is something that neither I personally nor any of my work collegues have ever encountered before. Making matters more strange instead of more clear.
Now you should be able to guess why this question has this specific subset of the arduino community as a target audience:
Is / Was there any point where such behaviour was encountered in the many years arduino is a thing now? Is there anything specifically known about the specific firmware of the bridge I have on my board? (I read the flash of that IC into a hex file and you find the SHA256 of it below)
that is anywhere near up that alley? Since I dont know where to find the changelogs for the USART to USB Bridge firmware (and honestly am not even willing to read through years of backlogs not even exactly knowing if there is anything to find in the first place and not even knowing what exactly to
look for...) I thought I could rather ask here if any body here recalls such a situation.
SHA256 of the USB to serial bridge firmware:
e8bfe5ce9253c8841ef1ca10a76eda051f1a8ef9f0fc1df9bff46fead917256a
Some words to end:
I am a student in embedded systems programming writing code for over half of my life now.
The Code for the main processor is tested. Since it works flawlessly with the external bridge I do explicitly not suspect the problem there. Thus I dont see any neccessity to post it anywhere...
Message to the moderators:
Should you happen to find any place better suited for this question within this forum feel to move it there.