增加了CAN中断优先级错误引起的通信debug案例

This commit is contained in:
NeoZng 2023-03-23 19:40:36 +08:00
parent b85eff52ba
commit 462a5e0654
3 changed files with 14 additions and 4 deletions

View File

@ -141,7 +141,6 @@ modules/can_comm/can_comm.c \
modules/message_center/message_center.c \
modules/daemon/daemon.c \
modules/vofa/vofa.c \
modules/ps_handle/ps_handle.c \
application/gimbal/gimbal.c \
application/chassis/chassis.c \
application/shoot/shoot.c \
@ -263,7 +262,6 @@ C_INCLUDES = \
-Imodules/message_center \
-Imodules/daemon \
-Imodules/vofa \
-Imodules/ps_handle \
-Imodules
# compile gcc flags

View File

@ -10,7 +10,7 @@ LEDInstance *LEDRegister(LED_Init_Config_s *led_config)
{
LEDInstance *led_ins = (LEDInstance *)zero_malloc(sizeof(LEDInstance));
// 剩下的值暂时都被置零
led_ins->led_pwm = GPIORegister(&led_config->pwm_config);
led_ins->led_pwm = PWMRegister(&led_config->pwm_config);
led_ins->led_switch = led_config->init_swtich;
bsp_led_ins[idx++] = led_ins;

View File

@ -87,7 +87,7 @@ long long的范围比float小。无符号和有符号数直接转换可能变成
## 典型debug案例
## 典型debug案例
这是一个结合了软件和硬件且有多模块耦合的异常。该bug发生在调试平衡步兵的底盘过程当中。
@ -159,3 +159,15 @@ void MotorControlTask()
均衡总线负载,调节任务运行时间。
# 典型debug案例二
这仍然是一个CAN总线引发的bug。使用的电机均为DJI电机。当多个电机接入时会产生反馈值跳变的情况。起初认为**总线负载过高**控制频率为500Hz反馈频率均为1kHz计算之后得出CAN的负载率接近90%),但将电机减少为一半甚至更少时仍然出现此问题。**单独使用CAN1且仅挂载一个电机则问题消失**同时使用CAN1和CAN2不论单个总线挂载几个电机则问题再次出现。
**单步调试发现反馈值并未因指针越界而被纂改**。仔细检查代码的计算发现并未出错打开Ozone查看反馈值曲线发现确实偶发跳变但跳变值并未超出反馈值范围即即使发生跳变值仍然在**正常范围内**,因此不像是总线负载过大导致数据帧错误或指针越界修改的随机值。加入多个电机同时查看反馈值,**发现反馈跳变之后会和另一电机的反馈值相同**呈现“你跳到我我跳到你”的图景。怀疑CAN中断被**重入**即一个中断未完成时另一个CAN报文到来打断了当前的中断并执行了**相同的反馈解码函数**。但CAN1和CAN2的中断优先级均为5因此不可能打断彼此。打开CubeMX查看初始化配置发现两个CAN的FIFO0和FIFO1中断优先级不同分别是5和6。则FIFO1的溢出中断会被FIFO0打断且我们在电机的解码函数中使用了一些**静态变量**用于存储触发接收中断的电机报文的相关信息,故而新进入的中断覆写了之前中断的静态变量值,使得之前中断在恢复之后存储了前者的值,导致自身反馈错误。
将优先级统一设为5编译之后重新运行反馈值正常。
> “同时使用CAN1和CAN2不论几个电机则问题再次出现。” 导致此问题的原因是初始化CAN时按照rxid分配FIFO因此注册的电机会被交替分配到不同的FIFO故不论注册了几个电机只要多于2、注册到哪条总线都会出现FIFO1中断被FIFO0打断的情况。