As shown in the figure below, why does using RGU reset timer1 modify the data in memory 0x2000 0000?
The microcontroller model is LPC4357
如下图所示，请问为什么使用RGU复位定时器1会修改内存0x2000 0000的数据？
单片机型号是LPC4357
This is really confusing 这真是令人感到困惑
目前测试情况来看就是这样，0x2000 0000地址的这一个Byte，在不为0的情况下赋予某些特殊值，执行Timer1复位，就会出现这种情况。受影响范围我目前观测到的结果是0x2000 0000地址开始的前8个字节，至于会不会影响其他什么地方，我也看不到，毕竟我也不能把所有136K内存全部过一遍对吧。
具体小于多少，我没测，反正我测过0xAA，正常，0xFF正常，0x1C不正常，0x0B不正常，0x0C不正常。
至于我怎么发现的，好巧不巧有一个变量占用一个Byte，被编译器分配到了这里，这个变量很关键，一旦出错整个系统就会出错，我发现系统出错后无论怎么看代码都不觉得有问题，.map找到这个变量位于0x2000 0000之后单步调试，定位到执行Timer1复位时这个变量就G了，然后我就顺势研究了一下到底是怎么回事，就有了我俩对话里的那么多图。也如你所见，为了排除各项影响，我是直接在SystemInit里执行的测试代码，也屏蔽了M0内核，寄存器的值和汇编代码我看没什么问题，也贴在对话里了，唯独内存会出错。
如果你手里有LPC4357的话也可以测试一下，我这已经测试过2片板子都是这样，我的单片机完整型号是LPC4357FET256，生产批次ESD17160A。
//******************************************以上是历史消息******************************************
不好意思是我2B了，屏蔽M0内核的代码是0x01000002才对，不是0x10000002，这样子执行结果就对了，没有内存受到影响。
看上去这个问题是复位RGU的库函数错误地启动了M0内核，M0内核工作之后更改了内存导致的。
没事了没事了，此贴终结，又虚惊一场，想用好这个单片机可真不容易
Dude, we found a bug in this microcontroller.
As shown in the figure, the value of RGU_TIMER1_RST is 0x0000 0021, and the actual code after calculation is <LPC_RGU->RESET_CTRL[1] = 1 << 1;>, which is correct from the data sheet.
I don't need the library function, I directly run <LPC_RGU->RESET_CTRL[1] = 1 << 1;>, the result is still the same, the 8 bytes starting from 0x2000 0000 will be changed due to the reset of Timer1.
Or do you give feedback to the leadership? Maybe we can add a little to the errata book?
老兄，我们发现了这个单片机的一个BUG耶。
如图所示，RGU_TIMER1_RST的值是0x0000 0021，计算后实际的代码就是<LPC_RGU->RESET_CTRL[1] = 1 << 1;>，从数据手册上来看这么配置是正确的。
我不用库函数，直接运行<LPC_RGU->RESET_CTRL[1] = 1 << 1;>，结果还是一样的，0x2000 0000开始的8个字节会因为Timer1的复位而发生改变。
要么你向领导反馈一下？也许咱俩可以在勘误手册上添上一笔？
不可以哦，这个寄存器是Write Only的，另外，我做了下测试，前八个值给0xFFFFFFFF 0xFFFFFFFF，或者0x00000000 0x00000000，或者0x000000AA 0x00000000，都没有问题。唯独0x2000 0000开始的第一个字节小于一定值的时候才会出现这种问题，受影响的范围应该是前8个字节。
给你看个更有意思的执行结果，我觉得这石锤是个BUG了，只是我运气不好，把有一个关键变量放在0x2000 0000引起系统崩溃了，才发现了这个问题，如果是其他人，也许这里放的是个不重要的变量还看不出什么问题。
为了排除M0内核对内存产生影响，我让M0内核保持复位状态，结果还是一样的
目前测试情况来看就是这样，0x2000 0000地址的这一个Byte，在不为0的情况下赋予某些特殊值，执行Timer1复位，就会出现这种情况。受影响范围我目前观测到的结果是0x2000 0000地址开始的前8个字节，至于会不会影响其他什么地方，我也看不到，毕竟我也不能把所有136K内存全部过一遍对吧。
具体小于多少，我没测，反正我测过0xAA，正常，0xFF正常，0x1C不正常，0x0B不正常，0x0C不正常。
至于我怎么发现的，好巧不巧有一个变量占用一个Byte，被编译器分配到了这里，这个变量很关键，一旦出错整个系统就会出错，我发现系统出错后无论怎么看代码都不觉得有问题，.map找到这个变量位于0x2000 0000之后单步调试，定位到执行Timer1复位时这个变量就G了，然后我就顺势研究了一下到底是怎么回事，就有了我俩对话里的那么多图。也如你所见，为了排除各项影响，我是直接在SystemInit里执行的测试代码，也屏蔽了M0内核，寄存器的值和汇编代码我看没什么问题，也贴在对话里了，唯独内存会出错。
如果你手里有LPC4357的话也可以测试一下，我这已经测试过2片板子都是这样，我的单片机完整型号是LPC4357FET256，生产批次ESD17160A。
//******************************************以上是历史消息******************************************
不好意思是我2B了，屏蔽M0内核的代码是0x01000002才对，不是0x10000002，这样子执行结果就对了，没有内存受到影响。
看上去这个问题是复位RGU的库函数错误地启动了M0内核，M0内核工作之后更改了内存导致的。
没事了没事了，此贴终结，又虚惊一场，想用好这个单片机可真不容易
我把库函数改成这样就可以了，多谢你的留言，祝升职加薪
In order to rule out what you said, I put this code into SystemInit() to execute, as you know, this function is executed before the main() function, the code executed here cannot be affected by RTOS, interrupt or something else.
为了排除你所说的情况，我把这段代码放到SystemInit()里面执行，正如你知道的那样，这个函数是在main()函数之前执行的，在这里执行的代码不可能受到RTOS、中断或其他什么的影响。
你好，并不是这个原因，我是先发现某个变量的值有异常，再找到这个变量位于0x2000 0000的。所以我去找是什么原因导致这个变量的值出现异常。 就如图上所示一样，我是在单步调试运行，执行这3行代码的时候，不可能还有其他的位于0x2000 0000的变量发生改变。而且在最后一张图的调试过程中，我是在”Options for target“里面屏蔽了0x2000 0000，我指定可用RAM地址从0x2000 0010开始，编译器不会在0x2000 0000至0x2000 0010区间内放置变量。
Hello, this is not the reason. I first found that the value of a variable was abnormal, and then found that the variable was located at 0x2000 0000. So I went to find what caused the value of this variable to be abnormal. As shown in the figure, I am running in single-step debugging. When executing these 3 lines of code, it is impossible for other variables located at 0x2000 0000 to change. And in the debugging process of the last picture, I masked 0x2000 0000 in "Options for target", I specified that the available RAM address starts from 0x2000 0010, and the compiler will not place variables in the range of 0x2000 0000 to 0x2000 0010.
