dsPIC33EP512MU810在另一个UART上发送时在一个UART上出现帧错误

看起来很像“电问题”-串音？或一些-特别是很难找到-软件错误眨眼：



      以下为原文

    Looks a lot like "electrical problems" - crosstalk ?
Or some - especially hard to find - software bug  wink:

在一个串行端口上缺少接地连接？



      以下为原文

    Missing ground connection on one of the serial ports?
 

嗨，你检查了3个UART错误的DSPIC33 EP512MU810不影响您的程序吗？（请参阅ErrasaSeTeT）。如何检测帧错误？你写了一个错误处理程序吗？你在设计中使用25MHz XTAL吗？当做



      以下为原文

    Hi,
Did you check the 3 UART erratas of dsPIC33EP512MU810 do not affect your program ?
(see erratasheet).
How do you detect the frame error ?  Die you write an error handler ?
Are you using a 25MHz XTAL in your design ?
Regards
 

谢谢你的回复。我会和我们的电子学人员核对一下串扰的可能性。“所有的软件都有bug”，所以还是有可能的。我正在考虑不间断地传输，看看它是否改变了什么。关于勘误表，我没有看到影响我的UART勘误表：16：我使用UTXISEL＝0，所以不应用17:我不认为这些设备中的任何一个使用BRK，所以不应用18：我离开UART启用A。时间不多，所以我也没有看到任何可能影响波特率产生或导致时钟偏移的勘误表。我一直在使用错误处理程序中断，但是它调用了与RX中断相同的代码（这也处理了错误）。我正在尝试一个单独的错误中断，看看是否有帮助。我们有一个12MHz的TCXO在我们的设计，所以我们可以使用USB，这是通过一个缓冲器（NC7WZ125）到DSPIC时钟输入引脚63（OSC1）。THE为25MHz。我对PLL设置相当确定，因为其他非常严格的定时（即，汇编代码到时钟输出数据）在系统中运行良好。



      以下为原文

    Thanks for your responses.
 
I'll check with our electronics guys about the possibility of crosstalk or bad grounds.
 
"All software has bugs" so that's still a possibility.  I'm considering trying transmits without interrupts to see if it changes anything.
 
Regarding the errata, I see nothing about the UART errata that affects me:
16: I'm using UTXISEL=0, so does not apply
17: I don't think any of these devices use BRK, so does not apply
18: I am leaving the UARTs enabled all the time, so does not apply
 
I also see nothing in the errata about anything that could affect baud rate generation or cause clock skew.
 
I have been using an error handler interrupt, but it was calling the same code as the RX interrupt (which also handled errors).  I'm trying a separate error interrupt to see if that helps.
 
We have a 12MHz TCXO in our design so we can use USB, which is going through a buffer (NC7WZ125) to the dsPIC clock input on pin 63 (OSC1).  Tcy is 25MHz.  I'm fairly sure about the PLL settings because other very strict timings (ie, assembly code to clock out data) in the system are working well.