Hello, Im using CH583M as a peripheral and central device for scanning the air around and also for advertising with further connection in a server role. In parallel with this functionality, I have a set of functions for working with incoming custom requests from outside via UART1, for their decryption and for their parsing. And all this functionality is included in a separate custom TMOS event that is launched at the moment new data is received via UART1.

   The problem is that at a completely random moment, when only scanning, advertising and parsing requests are working on the device, the device stops working and gets stuck inside the BLE stack at address 0x41de6 - 0x41d84. The problem is that the device does not even reboot, but remains smoking in these addresses until it is rebooted via power, although I have implemented a restart based on an interrupt. That is, apparently all my interrupts are disabled and then this freeze occurs.

   I'm using version 2.1 of the BLE stack, the same thing happens on version 2.0. I tried all possible situations, nothing helps. The project was made on the basis of the official examples "central" and "peripheral". Freezing occurs quite rarely and the BLE connection has never been made during all this time. What could be the problem?

建议添加PC指针的方式进行观察运行的状态。如果出现卡死，可能是中断标志未清除或者死循环。通过PC指针可以观察到。

根据上面描述有使用串口接收方式，如果是使用了串口中断，可以先去掉串口功能进行测试，查看是否卡死。

CH57x/CH58x/CH32V wch risc-v 芯片hardfault问题追踪&程序卡死追踪 - iot-fan - 博客园 (cnblogs.com)

The problem has been resolved.

The problem was that I called tmos_start_task inside the UART RX interrupt handler. And since I had a huge stream of data via UART, the same task was started a huge number of times per second. I removed the task call from the interrupt and limited its call to once per unit of time, this solved my problem.

 But the device did not restart because the freeze occurred inside the priority interrupt handler.

需要注意不要在中断服务函数中调用TMOS任务。

如果卡死在中断，大概率是中断标志没有及时清除，例如串口中断，查看串口的数据是否及时取走。