增加了CAN中断优先级错误引起的通信debug案例
This commit is contained in:
parent
b85eff52ba
commit
462a5e0654
2
Makefile
2
Makefile
|
@ -141,7 +141,6 @@ modules/can_comm/can_comm.c \
|
||||||
modules/message_center/message_center.c \
|
modules/message_center/message_center.c \
|
||||||
modules/daemon/daemon.c \
|
modules/daemon/daemon.c \
|
||||||
modules/vofa/vofa.c \
|
modules/vofa/vofa.c \
|
||||||
modules/ps_handle/ps_handle.c \
|
|
||||||
application/gimbal/gimbal.c \
|
application/gimbal/gimbal.c \
|
||||||
application/chassis/chassis.c \
|
application/chassis/chassis.c \
|
||||||
application/shoot/shoot.c \
|
application/shoot/shoot.c \
|
||||||
|
@ -263,7 +262,6 @@ C_INCLUDES = \
|
||||||
-Imodules/message_center \
|
-Imodules/message_center \
|
||||||
-Imodules/daemon \
|
-Imodules/daemon \
|
||||||
-Imodules/vofa \
|
-Imodules/vofa \
|
||||||
-Imodules/ps_handle \
|
|
||||||
-Imodules
|
-Imodules
|
||||||
|
|
||||||
# compile gcc flags
|
# compile gcc flags
|
||||||
|
|
|
@ -10,7 +10,7 @@ LEDInstance *LEDRegister(LED_Init_Config_s *led_config)
|
||||||
{
|
{
|
||||||
LEDInstance *led_ins = (LEDInstance *)zero_malloc(sizeof(LEDInstance));
|
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;
|
led_ins->led_switch = led_config->init_swtich;
|
||||||
|
|
||||||
bsp_led_ins[idx++] = led_ins;
|
bsp_led_ins[idx++] = led_ins;
|
||||||
|
|
14
如何定位bug.md
14
如何定位bug.md
|
@ -87,7 +87,7 @@ long long的范围比float小。无符号和有符号数直接转换可能变成
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## 典型debug案例
|
## 典型debug案例一
|
||||||
|
|
||||||
这是一个结合了软件和硬件且有多模块耦合的异常。该bug发生在调试平衡步兵的底盘过程当中。
|
这是一个结合了软件和硬件且有多模块耦合的异常。该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打断的情况。
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue