- 博客(3)
- 资源 (3)
- 收藏
- 关注
RSS订阅原创 一场74HC595损坏迷雾
因此可以推定，可能芯片在某种特定条件下，前级输出与后级电压出现严重不匹配而损坏了后级的输入端子。这种特定条件可能是感应雷事件或者一个快速的电压阶跃，在电源上耦合了一个电压，而磁珠隔离这个电压变化，从而导致前后级的输出不匹配从而损坏后级的输入。在某种设备中使用了如下电路，CPU通过串行配置74HC595，74HC595每两个一组，由通过磁珠隔离的3.3V供电。这些设备用了十多年后，开始陆续出现故障，故障原因为74HC595失效，失效位置出现在 A1、B1、C1这三个位置之中的一个、二个或三个。
2023-11-09 11:35:04
494
1
原创 GD32F405 Timer单脉冲模式的一个疑似BUG
使用的计时器为Timer2，用到Timer2的CH0为外部触发输入（低电平有效），Timer2的CH3为触发后延迟和加宽后的脉冲输出（低电平有效）。CH0的触发信号第二次到来之后，CH3输出恢复到高电平，并在正常延迟后输出低电平，在预定计数周期之后正常恢复到高电平。目前暂时无法确定相关故障现象的原因，推测为CPU的O3CPRE信号在第一次触发后，未能够在计数溢出后正常切换电平。CH0的触发信号第一次到来之后，CH3正常延迟输出低电平，但是未在预期的计数周期后恢复到高电平。
2023-06-02 17:31:33
437
2
原创 GD32F405 SPI CRC校验的一个BUG
代码如上所示，CRC状态错误在spi_crc_next(SPI0)语句后发生。该语句后状态立即变为0x53，表示出现了接收溢出和CRC校验错误、发送缓冲区空、接收缓冲区非空。正常情况应该是在该语句后状态为0x82，表示正在收发，发送缓冲和接收缓冲都是空的。虽然发生了CRC校验错误和接收溢出错误，但是所有接收到的数据、读取的CRC、计算的CRC都是正确的。因此直接对比CRC数值，而不是判断CRC状态，可临时修正该问题。所使用的SPI 接收CRC校验一直是正确的，这次配置了一下看门狗，就频繁报CRC错误了。
2023-05-10 13:06:44
650
1
Python从PDF中提取表格
2020-01-04
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人