PIC16F18313未记录的错误：同步模式下的USART丢失数据

你好，我从来没有使用过这个论坛，但是我使用PIC单片机已经有很长时间了。最近，我想我在PIC16F18313 EASART1中发现了一个硅错误。当使用同步模式时，如果写入最后一个字节是TRAN时，数据可能丢失（丢失的数据和时钟）。StFrand（在TSR）中，它是最后一个比特（第七或第八）。我在“Meal.C”中提供了一个示例代码，其中有两个测试（只是取消了Meal.C中的一个测试行来选择测试）：测试是用16MHz的内部振荡器用2x PLL完成的。在相同的结果下，使用XC8 1.44（MPLAX 4.01中的默认设置）在空闲模式下编译。硬件测试是PIC16F18313 Rev 200 4H（A4）。Test1：执行对传输的延迟增加，在Seop.Test2上显示正确和不正确的传输：执行对传输。使用Test1和多比特模式的有问题的延迟来显示哪些位被正确地通过该线发送（它也在每对之前重置EUSAT以获得相同的结果）。注意：如果测试是使用其他波特率/ CPU速度执行的，则必须相应地调整延迟。EST结果：Test1R.Pult.PNG：在这里，您可以看到对6、9和10 Test1ReultToGoulvsBad的截断时钟：这里来自一个正确传输（16个时钟）的变焦数据，然后是截断传输（9个时钟）。它显示了一组具有不同位模式的截断传输。它表明前8位被传输OK，只有第二字节的第一位被转移。解决方法：如果你想继续使用双缓冲功能（如我所愿）：没有。有什么建议吗？如果您能够释放双缓冲功能：没有中断：仅在最后一个字节完全移位时才将数据写入TXREG：TopeTeTrMT（而不是TXIF）。中断：使用定时中断写入TxReg（而不是TXIF）。结论：这应该包含在勘误表文件和同一个家庭的其他设备测试，以了解所有受影响的设备/修订。如果可能的话，它应该被固定在下一个受影响的设备的硅修订。我还没有能够测试最新的PIC16F18313硅修订版（A6），因为所有购买的设备似乎仍然是静止的。A4



      以下为原文

    Hello.
I've never used this forum, but I've been using PIC microcontrollers for a long time.

Recently, I think I've found a silicon bug in the PIC16F18313 EUSART1.
When used in synchronous mode, data may get lost (missing data and clock) if write to the TXREG is done when the last written byte is transferring (in TSR) it's last bits (7th or 8th).

I've provided a sample code in "main.c" with two test (just uncomment one of the test lines in main.c to select the test):

Testing is done using internal oscillator at 16Mhz with 2x PLL.
EUSART baudrate is set to 1Mhz (Speeds from 1-4Mhz have been tested with same results).
Compiled in free mode using XC8 1.44 (and default settings in MPLAB X 4.01).
Hardware tested is PIC16F18313 rev 2004h (A4).

Test1: executes pairs of transfers with an increasing delay, showing both correct and incorrect transfers on the scope.
Test2: executes pairs of transfers with using a problematic delay from test1 and multiple bit patters to show which bits are correctly send through the wire (It also resets the EUSART before each pair to get the same result each time).

Note: If testing is performed using other baudrates / CPU speeds, delays must be adjusted accordingly.

Test Results:

Test1_result.png: Here you can see truncated clocks at pair 6,9 and 10.

Test1_result_good_vs_bad: Here the zoomed data from one correct transfer (16 clocks) followed by a truncated transfer (9 clocks).

Test1_result.png: This last one is the result of test2. It shows a set of truncated transfers with different bit patterns.
It shows that the first 8 bits are transfered ok and only the first bit of the second byte is transfered.

Workarounds:

• If you want to keep using the double buffer functionality (as I wanted):
  
  • NONE. Any suggestions?
    
• If you can afford to loose the double buffer functionality:
  
  • Without interrupts: Poll the TRMT (instead of TXIF) to write data to TXREG only when last byte has been completely shifted.
  • With interrupts: Use a timer interrupt to write to TXREG (instead of TXIF).
    
  
  

Conclusions:

• This should be included in the errata documents and tested with other devices of the same family to know all affected devices/revisions.
• If possible, it should be fixed on next silicon revisions of affected devices.
• I've not been able to test the newest PIC16F18313 silicon revision (A6) because all devices bought seem to be still A4.
  

   Attached Image(s)


Attachment(s)

main.c (5.14 KB) - downloaded 36 times