我正在嵌入式Linux设计中的SC16IS752芯片上工作。在串行活动的正常条件下，该芯片在两个COM端口上都能很好地工作。然而，我们发现，在串行会话中，当您在大约30秒内不发送或接收数据时，在TX线上传输的下一个字节会以38400及以上的所有波特率进行位移。有趣的是，这个问题在19k波特或更低（波特率较慢）时不会发生。
波特率越高，问题就越严重。在38k波特时，传输的字节被移位1位（尝试发送0x66，0xB3被发送）。在115k波特时，传输的字节被移位4位（尝试发送0x66，0xF6被发送）。
此问题仅在现有串行会话中处于非活动状态30秒后发生。这意味着新串行会话的第一个字节始终正确传输。
如果您等待30秒，而在NXP芯片上接收到一个字节，这会使NXP芯片处于一个良好的状态，随后传输的字节会正确传输（只要它比接收到的字节晚不到30秒）。
我浏览了SC16IS752数据表、应用程序说明和勘误表，但都无济于事。我研究了睡眠模式、接收超时和所有状态寄存器。我也尝试过在传输数据之前清除传输fifo。我已经用完了要尝试和调试的东西。我知道，通过Linux驱动程序中的调试，我正在通过SPI将正确的字节发送到NXP串行芯片。
顺便说一句，我正在使用的Linux驱动程序是由Manuel Stahl编写的，他将其发布在Linux内核邮件列表上，试图将其放入Linux内核，但没有成功。
后来的调查显示：
我们已经连接了一个内联RS-232设备，它使用LED显示所有引脚的状态。我注意到，我们的SC16串行芯片（配置为DTE）在Tx或Rx交易后，其"TD"one_answers"RTS"灯将激活32秒，此时TD和RTS灯都熄灭。
这意味着SC16芯片有一个32秒的超时时间，在该时间点，它会停用这些引脚。在这一点上，Tx事务（具有SC16芯片发送数据）将导致比特移位问题（如前所述，只有第一个字节被比特移位）。
这里有一个有趣的部分：使用一台带有Windows和"RealTerm"的调试笔记本电脑作为CTE（在SC16串行连接的另一端），它允许我们切换"CTS"引脚。当我切换此引脚（打开或关闭）时，它会"唤醒"SC16芯片的TD和RTS灯，此时Tx事务（让SC16芯片发送数据）将成功！
所以总结是：
- 当SC16芯片的TD和RTS灯亮起时，随后的Tx事务就成功了
- SC16 TD和RTS灯在32秒后超时（熄灭）。随后的Tx事务存在位偏移问题
- 当我通过切换CTE的RTS引脚来拨动SC16芯片时，它会"唤醒"SC16芯片的TD和RTS灯，随后的Tx事务成功
我在SC16数据表中没有看到任何提到这种类型的超时。唯一提到的是我禁用的"睡眠模式"。
我发现了问题。问题是，我们使用的是ISL4270E RS232电平转换器（而不是SC16IS752演示板中使用的SP3243E），它支持自动断电功能，在30秒不活动后关闭芯片电源。当它检测到数据并通电时，就会出现问题，因为它的速度不够快，无法以115k波特发送所有比特。这就是为什么在较高的波特率下，位移问题会更糟。