已经解决问题了
但是好像应该感谢chatgpt，又好像它没帮到我什么
首先说一下为什么要感谢，因为的确给我指了个方向，我把其他时钟都关闭了，解决了问题，然后把关闭掉的时钟一个一个开起来，把问题定位到了特定时钟内部的代码——这个解题思路有没有chatgpt我都会这么干，就是一部分一部分disable代码，然后一点点查，给我的帮助就是直接帮我定位到是其他时钟，所以算给我节省了一点时间。
但是——chatgpt现在给我的感觉就是一个百度百科爬虫，只不过把所有其他人的答案组织成人类语言，呈现给我，至于有没有独立解决问题。。。它就是个爬虫而已，目前仅仅可以定位成（垃圾&重复）信息过滤器
=========================================================================

然后详细说一下技术问题
的确很奇怪
请看如下代码
(p_Sample!=(&SampleCharastic[MAX_SAMPLE-1]))?(p_Sample++):(p_Sample=&SampleCharastic[0]);
和
(p_Sample<(&SampleCharastic[MAX_SAMPLE-1]))?(p_Sample++):(p_Sample=&SampleCharastic[0]);
这是问题代码，第一个是初始代码，第二个是我定位到问题之后修改的代码
所以感觉很奇怪。
我定义了一个数组SampleCharastic[]，然后拿个指针指向数组的[0]位，然后逐步增大指针，当指针指向这个数组的最后一个元素的时候，把指针拨回[0]
自然，当指针不等于最后元素的地址的时候，指针增大，等于最后地址，那就归0，没错吧？
但是不知道为什么用【不等于】最后这个指针（已经定义p_Sample是char指针了）会指向一个函数地址，所以最后程序跑飞了
但是用了【小于】符号之后，就正常了
所以这到底怎么肥四？C数据类型检查不严格的锅？

【 在 lvsoft 的大作中提到: 】
: 当你在多个中断源之间遇到问题时，存在多种可能的原因。即使你认为其他时钟不应该影响当前的行为，它们仍然可能会间接影响系统的行为。以下是一些可能的原因：
: 中断嵌套：STM32支持中断嵌套。这意味着当一个中断正在执行时，如果另一个优先级更高的中断被触发，那么当前的中断会被暂停，直到优先级更高的中断执行完毕。如果你的中断优先级设置不正确，这可能导致不可预测的行为。
: 共享资源：两个或多个中断例程可能共享某些资源，例如全局变量、外设或内存。如果在中断服务例程中没有正确管理这些共享资源，可能会发生竞态条件，导致系统崩溃。
: ...................
--
FROM 180.116.135.*