A couple more data points. I pulled the problematic hat board from the PI 4 and connected that same PI 4 to the other protoboard that does not exhibit the problem. There was no problem with serial communication. That rules out differences between the heat sinks on the PI boards.
So, I assumed there may be a problem with a solder joint on the hat board or the ZIF socket. I decided to solder up another hat board using a 28 pin DIP socket instead of the ZIF socket. This is more similar to the protoboard that works with no issues. I plugged this new hat board into the same PI 4 I tested successfully with the protoboard. The uart communication corruption problem occurred again under the same circumstances.
I'll try some different AVR micro-controllers tomorrow to make sure that isn't the problem. But, I already tried that with the other hat board that showed the same problem with no luck. So, I am not expecting anything to change. I'll also triple check the schematic for the protoboard and the hat boards to see if there is a difference that can explain this. Since I have checked it before, I seriously doubt I will find something.
I can't think of what could be the problem with these hat boards and I doubt I created the same solder cold joint on both boards that causes both boards to have problems with two different uarts that start at the same time/temp.
BTW, the default console uart is working just fine on both hat boards using an off-the-shelf RS-232 level driver. No corruption issue. In addition, uart 2 on the PI 4 on both hat boards is used to program the AVR. It never exhibits a problem. However, I assume UPDI protocol that is used to program the AVR has some error detection and correction. But, I don't detect any difference in the time it takes to program the part once the PI gets hot enough to cause significant data corruption on uarts 3 and 4.
The protoboard and the two hat boards utilize the same decoupling capacitors for the AVR. And as I mentioned before, a USB serial adapter connected to the same hat board that is exhibiting data corruption on one uart does not exhibit data corruption on the other AVR uart connected to the USB adapter.
I'm still at a loss how to fix this one.
So, I assumed there may be a problem with a solder joint on the hat board or the ZIF socket. I decided to solder up another hat board using a 28 pin DIP socket instead of the ZIF socket. This is more similar to the protoboard that works with no issues. I plugged this new hat board into the same PI 4 I tested successfully with the protoboard. The uart communication corruption problem occurred again under the same circumstances.
I'll try some different AVR micro-controllers tomorrow to make sure that isn't the problem. But, I already tried that with the other hat board that showed the same problem with no luck. So, I am not expecting anything to change. I'll also triple check the schematic for the protoboard and the hat boards to see if there is a difference that can explain this. Since I have checked it before, I seriously doubt I will find something.
I can't think of what could be the problem with these hat boards and I doubt I created the same solder cold joint on both boards that causes both boards to have problems with two different uarts that start at the same time/temp.
BTW, the default console uart is working just fine on both hat boards using an off-the-shelf RS-232 level driver. No corruption issue. In addition, uart 2 on the PI 4 on both hat boards is used to program the AVR. It never exhibits a problem. However, I assume UPDI protocol that is used to program the AVR has some error detection and correction. But, I don't detect any difference in the time it takes to program the part once the PI gets hot enough to cause significant data corruption on uarts 3 and 4.
The protoboard and the two hat boards utilize the same decoupling capacitors for the AVR. And as I mentioned before, a USB serial adapter connected to the same hat board that is exhibiting data corruption on one uart does not exhibit data corruption on the other AVR uart connected to the USB adapter.
I'm still at a loss how to fix this one.
Statistics: Posted by d1g1t4l_g33k — Sun May 05, 2024 5:50 am