? ?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指針的方式進行觀察運行的狀態(tài)。如果出現(xiàn)卡死，可能是中斷標志未清除或者死循環(huán)。通過PC指針可以觀察到。

根據(jù)上面描述有使用串口接收方式，如果是使用了串口中斷，可以先去掉串口功能進行測試，查看是否卡死。

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.

需要注意不要在中斷服務(wù)函數(shù)中調(diào)用TMOS任務(wù)。

如果卡死在中斷，大概率是中斷標志沒有及時清除，例如串口中斷，查看串口的數(shù)據(jù)是否及時取走。