测试过GD32E103，GD32F303，都有这个问题，其它型号有待确认，大概率GD32全系CAN外设都有这个问题。
CAN状态寄存器的bit9 RS表示接收状态，实际测试，CAN初始化退出睡眠模式以后RS位就是1，进入初始化模式以后RS位清零，退出初始化模式以后RS=1
然后整个使用过程中这个RS位一直都是1，本来这个位是指示CAN硬件有没有在接收数据的，现在完全失去了意义。
CAN的一帧很长，需要上百个位，持续数百微秒，硬件接收完了完整一帧才会放入FIFO，软件才能查询到，所以如果软件想知道硬件是否在接收数据，这个接收指示位就很重要，如果这个位行为异常，软件通过RX管脚来判断是否CAN正在接收数据非常困难。
实测STM32和AT32的这个RS位行为是正常的，只有接收数据的时候才会置1，可以判断CAN的接收状态。
联系过GD原厂，确认了这个问题，GD32的CAN外设无法通过硬件判断CAN外设是否在接收数据，还有更坏的消息：原厂不认为这是bug，也不打算在新产品型号中更改。
好消息是他们的CAN IP是自研的，所以这个bug应该是GD32芯片独有的，不会影响其它厂商的产品。
附和原厂技术人员沟通记录：
GD：我找人测了下，默认是处于接收状态，如果是发送数据时，会处于发送状态，发的时候会变 0，其他都是1
ME：这种行为模式没有用处，因为实际需要的是硬件在接收数据才置1，而且其它厂家人家也是这么定义的
GD：设计就是这样，那就只能别这么用
ME：那应该如何判断CAN硬件在接收数据？有别的方法也行
GD：没有办法，就我跟你说的判断帧数量
ME：我说过了，没法根据帧判断，CAN总线在接受数据的时候，数据还没进FIFO，一帧接收完了才会进FIFO
GD：我知道你意思，那就无解啦，无法识别正在接收状态
ME：好吧，只能尽量避免用这个芯片了，这个IP不知道是自研的还是外购的，STM32F103是没有这个问题的
GD：自研
ME：那别家应该没这个问题，你们可以对比下友商的产品
GD：知道，设计人员对这个理解与别人有偏差，这就跟485接口类似
ME：就是受了RS485的影响，485不支持多主，发送完数据要设置为接收，问题CAN是支持多主的，没有这个问题，所以是芯片bug，不是特性
GD：485没有仲裁机制，CAN有仲裁机制，现在这个特性你认为是BUG那就是，他不影响正常使用，只是你刚好想要用的点有点特殊，无法满足你的应用场景
ME：这个位相当于没有，是不是bug，你们要确认，涉及到新芯片是否会更新的问题。
GD：我回你了啊，我们设计是我跟你说的那样，这个你能理解为他是bug，也能理解为他为设计特性
ME：我明白了，那就是以后新型号也不会更改。
最近编辑记录 echo (2022-01-04 19:19:01)
离线
原厂的借口挺搞笑。
类似客户需求是盖一个烟囱，然后他们设计人员把图纸看反了挖了一口井，客户给他们说你这不对啊，他们说：知道，设计人员对这个理解与别人有偏差。
离线
@XIVN1987
CAN的这个外设接口都是和STM32一样的。包括雅特力的AT32，行为都是一样的。明显GD32是个设计错误。这个错误导致了功能缺失，当然，如果这个功能你用不上的话最好。然而如果你的产品都出去了，客户反馈问题，希望升级固件解决问题的时候，就不会这么说了。
你这个方法如果熟悉CAN协议就会知道完全不可能实现。之所以要用这个位，就是因为性能问题，我的CAN负载率接近100%了。
你打算什么时候清这个IO的IF置位？1M波特率下1us一个中断你确定MCU能处理么？
离线
@XIVN1987
而且不是要知道开始接收一个帧，是要知道CAN是否在接收帧，是一个时间段，可能500us，可能1ms，软件在这个时间段里随时都有可能要判断。
这个功能就是RS位存在的价值，用硬件很容易实现。
离线
这么说吧，这个RS位判断接收状态，只要是做USBCAN设备，想做好一点，是必然要用上的。
离线
更新：STM32F103，AT32F413（雅特力），CH32F103（沁恒）他们的CAN在这个问题上表现是一致的。毫无疑问，GD32的这个是芯片CAN模块的bug。
最近编辑记录 echo (2022-01-05 08:46:54)
离线
感谢楼主踩坑，为其他人铺路
GD32F103是2013年发布的，所以，这个bug存在快9年了。
离线