From 462a5e065404facaa1c3125d651ea96da154ce9f Mon Sep 17 00:00:00 2001 From: NeoZng Date: Thu, 23 Mar 2023 19:40:36 +0800 Subject: [PATCH] =?UTF-8?q?=E5=A2=9E=E5=8A=A0=E4=BA=86CAN=E4=B8=AD?= =?UTF-8?q?=E6=96=AD=E4=BC=98=E5=85=88=E7=BA=A7=E9=94=99=E8=AF=AF=E5=BC=95?= =?UTF-8?q?=E8=B5=B7=E7=9A=84=E9=80=9A=E4=BF=A1debug=E6=A1=88=E4=BE=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Makefile | 2 -- modules/led/led.c | 2 +- 如何定位bug.md | 14 +++++++++++++- 3 files changed, 14 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index f6a50ab..7f97471 100644 --- a/Makefile +++ b/Makefile @@ -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 diff --git a/modules/led/led.c b/modules/led/led.c index 4b134ac..f3f4a38 100644 --- a/modules/led/led.c +++ b/modules/led/led.c @@ -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; diff --git a/如何定位bug.md b/如何定位bug.md index a2e521f..f82395c 100644 --- a/如何定位bug.md +++ b/如何定位bug.md @@ -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打断的情况。 +