PIC18F25K80 EUSART数据通过某些振荡器配置接收损坏

嗨，所有，我一直在跟踪一个问题与EASART模块，看起来像一个候选者的硅勘误表，但它目前没有记录。我想分享我的评论和可能的建议（当然，我可能会做错什么）。[侧记：我刚刚把我的项目从PIC18F4620移植到一个更新的设备，因为另一个EASART硅勘误表。在18F4620中，当TXREG与停止位（ErraTaA 33）相同的周期写入时，发送了一些额外的零字节。我没有收到问题，但建议的解决办法是不可接受的，所以我已经移动到18F25K80。我没想到会被另一个EuSART相关的问题所困扰。问题是：从中断处理程序内部的RCREG1读取（检查RCIF之后）返回一个与串行线上接收的字节不同的损坏字节。另外的证据（我做的测试结果）：1）数据正在SE中。NT来自PC计算机，但我确信字节在接收上损坏，而不是发送方的，因为我已经用USB逻辑分析仪检查了RX PIN。顺便说一下，这是异步串行（Syc＝0）。2）没有波特率不匹配：我知道波特率编程是好的，因为我看到TX的比特宽度与RX的比特宽度相同。顺便说一下，我使用了115200，并且所有的BRG编程都是由“我定义的X-TalthFRIQ”值参数化的。3）腐败是“振荡器依赖的”。在一定的条件下，根据时钟值，期望的0x00字节被转换成0x21或0x42。我的结果是（BRGH＝1和BRG16＝1）：3.1）振荡器＝16 MHz×4，PLL＝64 MHz＝&；RxReG1读取0x21而不是预期的0x03.2）振荡器＝iNoSc 8 MHz×4 PLL＝32 MHz＝& gt；RxReG1读取0x42而不是预期的0x00 OBs：是的，我们在这里看到一个模式构建…但是，4兆赫×4 PLL＝16兆赫，我的程序根本没有工作，我不想调查。我可以试试它的增益。3.3）振荡器= InOSC 16 MHz x 1（没有PLL）＝16兆赫＝gt；没有腐败！4小时）腐败也依赖于BRGH/BRG16设置。结果3.1至3.3已获得BRGH＝1和BRG16＝1。总结：4.1）振荡器＝16 MHz×4，PLL＝64兆赫，BRGH＝1，BRG16＝1＝&＞；腐败。4.2）振荡器＝16 MHz×4 PLL＝64兆赫，BRGH＝0，BRG16= 1＝&＞；不腐败。和4.3都使用不同的波特率公式“FoC//（16（n + 1）””比4.1“FoC//（4（n+1））”，所以似乎问题是依赖于振荡器设置和波特率发生器电路。5）尽管0x00＝& gt；0x21/0x42可能对一些额外的研究有用，但这并不是唯一的腐蚀。我见过。我还注意到其他不同的字节被破坏，我不确定腐败是否取决于接收的确切字节，或者是否与同时发送的字节有关。所以，不要把这个案子当作一个规则，它只是碰巧我重复了一个特定的协议，在某些特定的字节中最可能发生的腐败就像我提到的0x00，但并不总是这样。6）我检查了错误条件ORR和FER，没有一个。7）我认为它可能是一些K。IN的电气问题，所以我尝试添加更多的解耦电容器，更多的VDDCORL/VCAP，添加“坦克”钽电容器并联到陶瓷100NF解耦等没有变化。BTW，该设备正在运行5V。目前，我继续我的发展与4.3列出的设置。然而，能够使用其他波德率公式（4.1）是很好的，因为它在选择项目即将运行的更高波特率方面提供了更多的灵活性。



      以下为原文

    Hi all,

I've been tracking an issue with the EUSART module that looks like a candidate for silicon errata but it's currently not documented. I'd like to share my findings for comments and possible suggestions (of course, i might be doing something wrong).

[Side note: I've just ported my project from PIC18F4620 to a newer device due to another EUSART silicon errata. With 18F4620 I had some extra zero bytes being sent when TXREG is written in the same cycle as the stop bit (errata #33). I had no receiving problems there, but the suggested workaround was not acceptable so I've moved to 18F25K80. I didn't expect to be bitten by another EUSART related issue.]

The problem: reading from RCREG1 inside the interrupt handler (after checking RCIF) returns a corrupt byte that is different from the byte received on serial line.

Additional evidence (results from tests i've made):

1) The data is being sent from a PC computer, but I'm sure the byte is corrupt on reception, and not on sender's side, because I've checked with an u*** logic analyzer tapping on the RX pin. btw, this is async serial (SYNC=0).

2) There is no baudrate mismatch: i know my baud rate programming is good because I see on scope that TX's bit width are the same as RX's bit width. Btw, i'm using 115200 and it all BRG programming is parametrized by the "#define _XTAL_FREQ" value i use.

3) The corruption is "oscillator dependent". In a certain condition I see a expected 0x00 byte being turned into either 0x21 or 0x42, depending on the clock value. The results I have are (BRGH=1 and BRG16 = 1):
3.1) Oscillator = INTOSC 16 MHz x 4 PLL = 64 MHz => RXREG1 reads 0x21 instead of expected 0x00
3.2) Oscillator = INTOSC 8 MHz x 4 PLL = 32 MHz => RXREG1 reads 0x42 instead of expected 0x00
obs: yes, we see a pattern building here... but with 4 MHz x 4 PLL = 16 MHz my program didn't worked at all and i didn't care to investigate. i may try it gain.
3.3) Oscillator = INTOSC 16 MHz x 1 (NO PLL) = 16 MHz => no corruption! tested for hours flawlessly.

4) The corruption is also dependent on BRGH/BRG16 settings.The results 3.1 to 3.3 have being obtained with BRGH=1 and BRG16 = 1. Summarizing:
4.1) Oscillator = INTOSC 16 MHz x 4 PLL = 64 MHz, BRGH = 1, BRG16 = 1 => corruption.
4.2) Oscillator = INTOSC 16 MHz x 4 PLL = 64 MHz, BRGH = 0, BRG16 = 1 => no corruption.
4.3) Oscillator = INTOSC 16 MHz x 4 PLL = 64 MHz, BRGH = 1, BRG16 = 0 => no corruption.

Please notice that 4.2 and 4.3 both use a different baudrate formula "fosc/(16(n+1))" than 4.1 "fosc/(4(n+1))" so it seems the issue is dependent on both oscillator settings and and baud rate generator circuitry.

5) Although the 0x00 => 0x21/0x42 may be useful for some additional research, this is not the only corruption i've seen. I've also noticed other different bytes being corrupted and i'm not sure if the corruption depends on the exact byte being received or if it's related to the one being sent at the same time. So don't take this case as a rule, it just happens that i'm repeating a certain protocol and the corruption happens most likely in some specific bytes like the 0x00 i've mentioned, but not always.

6) I've checked for error conditions OERR and FERR and there is none.

7) I've thought it could be some kind of electrical problem so I've tried adding more decoupling capacitors, more vddcore/vcap, adding "tank" tantalum capacitors in parallel to the ceramic 100nF decoupling etc. No change. Btw, the device is operating with 5V.

Currently I'm continuing my development with the setting listed in 4.3. However it would be nice to be able to use the other baudrate formula (4.1) as it gives more flexibility in choosing the higher baudrates the project will be operating soon.

regards,

Miguel