I made a PCB board with STM32WB5MMG, which receives the data of max30112 through external falling edge interrupt and sends it through BLE notify. However, once I add the execution task UTIL_SEQ_SetTask(1<<CFG_TASK_SPO2_EVT_ID,CFG_SCH_PRIO_0); in HAL_GPIO_EXTI_Callback;
My program just fails.The interrupt callback function is shown in the figure below:
- If you comment UTIL_SEQ_SetTask( 1<<CFG_TASK_SPO2_EVT_ID,CFG_SCH_PRIO_0), the program runs normally.
- The task (CFG TASK SPO2 EVT_ID) just notify two uint8_t data with a value of 0.And I use a timer to trigger tasks regularly to verify that the characteristic of BLE notify is normal.(It's ok.)
At present, I guess that the EXTI and BLE notify features will conflict, or there is some problem between EXTI and UTIL_SEQ_SetTask. How can I verify it?
Thanks in advance.
1 ACCEPTED SOLUTION
Accepted Solutions
I made a PCB board using STM32WB5MMG, max30112 (sensor chip) and max30001 (sensor chip). I collected the signal by triggering an interrupt on the external falling edge and sent it through BLE notify. Max30112 has an interrupt pin MAX30112_INTB_Pin (PD0), max30001 There are two interrupt pins MAX30001_INTB and INT2B (PC10 and PC11). Task CFG_TASK_DDD_EVT_ID just notifies two uint8_t data with value 0.
- If I don't add the BLE notify task (CFG_TASK_DDD_EVT_ID), all three interrupts trigger normally and work fine.
- I added the CFG_TASK_DDD_EVT_ID task to the two interrupt pins of the MAX30001, MAX30001_INTB and INT2B, and they also worked fine.
- If I add UTIL_SEQ_SetTask(1<<CFG_TASK_DDD_EVT_ID,CFG_SCH_PRIO_0) to MAX30112_INTB_Pin (PD0), my device cannot broadcast (I cannot discover my Bluetooth device on my phone), and the green light on my PCB (PA11 set) is always on (This is the last line of instructions in my interrupt function), so I consider that the entire chip is stuck after triggering a MAX30112_INTB_Pin interrupt, but I don't know where it is finally stuck?
I would like to ask how to find out where my program is stuck. Or will EXTI0 (PD0) and EXTI15_10 (PC10 and PC11) produce different results from the task CFG_TASK_DDD_EVT_ID? HAL_GPIO_EXTI_Callback() is shown in the figure below:
I will attach the current URL of this problem to the previous two similar questions raised, and show that it has been solved in the reply.
I made a PCB board using STM32WB5MMG, max30112 (sensor chip) and max30001 (sensor chip). I collected the signal by triggering an interrupt on the external falling edge and sent it through BLE notify. Max30112 has an interrupt pin MAX30112_INTB_Pin (PD0), max30001 There are two interrupt pins MAX30001_INTB and INT2B (PC10 and PC11). Task CFG_TASK_DDD_EVT_ID just notifies two uint8_t data with value 0.
- If I don't add the BLE notify task (CFG_TASK_DDD_EVT_ID), all three interrupts trigger normally and work fine.
- I added the CFG_TASK_DDD_EVT_ID task to the two interrupt pins of the MAX30001, MAX30001_INTB and INT2B, and they also worked fine.
- If I add UTIL_SEQ_SetTask(1<<CFG_TASK_DDD_EVT_ID,CFG_SCH_PRIO_0) to MAX30112_INTB_Pin (PD0), my device cannot broadcast (I cannot discover my Bluetooth device on my phone), and the green light on my PCB (PA11 set) is always on (This is the last line of instructions in my interrupt function), so I consider that the entire chip is stuck after triggering a MAX30112_INTB_Pin interrupt, but I don't know where it is finally stuck?
I would like to ask how to find out where my program is stuck. Or will EXTI0 (PD0) and EXTI15_10 (PC10 and PC11) produce different results from the task CFG_TASK_DDD_EVT_ID? HAL_GPIO_EXTI_Callback() is shown in the figure below:
I will attach the current URL of this problem to the previous two similar questions raised, and show that it has been solved in the reply.
