运行TMOS系统的MCU复位/死机问题排查
TMOS是沁恒自主产权的轻量级操作系统，可以说是为沁恒的MCU量身定制的。
如果用户在使用TMOS系统时，出现复位问题，最常见原因是应用层代码的ram越界访问、操作flash没有4字节对齐。其他复位问题，可以参考下方博客，利用定时器中断、看门狗中断和硬件错误中断来定位复位前PC指针指向哪里：
CH582 CH592 CH573 PC指针打印（排查程序运行+死循环指示） - debugdabiaoge - 博客园 (cnblogs.com)
CH57x/CH58x/CH32V wch risc-v 芯片hardfault问题追踪&程序卡死追踪 - iot-fan - 博客园 (cnblogs.com)
如果应用层代码确实查不出问题了，以下结合TMOS系统的特性，提供一些排查建议及代码注意点：
Ⅰ.运行TMOS系统的代码，一定要严格遵循的代码逻辑：
①不要在中断服务函数中调用任何关于BLE库的接口函数，如开关广播的接口、安排TMOS事件执行的接口等。TMOS系统存在于BLE库中，中断服务函数中的处理是脱离TMOS的监控的，在中断服务函数中调用库接口，可能会导致出中断时被库覆写，导致未知问题，比如说按逻辑应该会被执行的事件，出中断后被协议栈覆写清掉了，连锁后果未知。
②应用层传参时一定要传递正确的、注册后的taskID。不可以反复注册同一个taskID即任务ID。taskID是8位数据，反复注册会导致同一个taskID不断+1，注册到255后溢出会导致复位等不可预期的影响。
③eventID即事件ID的定义一定要按位定义。可以用第n个eventID就“1左移n位”的方式来定义，n从0计起。出错后，事件没有按规划的逻辑运行，影响未知。
④ram的使用率不要卡的太极限，建议预留5K+的ram给局部变量/应用层堆栈使用（应根据应用层代码自行压缩/扩大余量，以实际运行不出问题为准）。可能会导致复位。
⑤使用到休眠时，中断服务函数必须加highcode修饰，放到ram里运行。若不加highcode修饰，休眠唤醒后，flash需要一定的时间来运行稳定，期间在flash中执行代码，可能会导致复位。
⑥（使用24年以前的早期版本EVT需要检查）安全寄存器的使能/失能，一定要成对使用。使用早期版本的EVT需要注意，最新EVT中已经加了处理，没有配对使用时会编译报错。
Ⅱ.运行TMOS系统的代码，建议遵循的注意点：
①taskID的注册，需要占用一定量的协议栈ram（由BLE_MEMHEAP_SIZE划分），数量较多时占用协议栈ram多，可能会影响TMOS系统的运行。协议栈ram不足会导致无线通信异常，比如说无法广播。
②如果没有使用到休眠，理论上中断服务函数可以不加highcode修饰（ram够用的话能加就加，中断尽量快进快出）。不加highcode修饰的缺点是中断服务函数的处理会慢一点，实际测试运行不出问题就行。
③（使用24年以前的早期版本EVT需要检查）clk.c公共文件，在24年后的EVT包中有更新，建议更新到与最新EVT一致，对32K频偏校准代码进行了优化。不更新的话可能会导致32K偏差大，不会导致32K不跑。
④（使用24年以前的早期版本EVT需要检查）标准C的内存管理函数是脱离TMOS系统监管的，在编译后ram的剩余量中申请，ram余量较小时可能会出问题。建议换用tmos开头的内存管理函数，是在TMOS系统监管下管理内存的，不会导致内存出错。最新EVT中在ld文件下加了应用层堆栈保护，不过还是建议用tmos开头的内存管理函数（tmos_msg_allocate和tmos_msg_deallocate）。
