又踩中一个坑

死不低头

H7果然很高端，把STM32F4上的程序移植上来跑着跑着死了，监控一看函数内部声明了一个uint32_t temp[2]的数组根本无效，只有temp[0]是对的，temp[1]不对，给这个元素赋值就进入MemManage_Handler了。然后把这个数组放到函数外面当全局的就正常，哪位大佬解释一下？

Penguins

数组放在什么区域了？检查 MPU 配置，考虑背景区无特权级是否可访问问题，及变量对齐问题。

lyj41801

局部变量，肯定是放在栈里面啦，看看是不是栈大小配置太小了嘛

死不低头

lyj41801 发表于 2025-6-20 11:30
局部变量，肯定是放在栈里面啦，看看是不是栈大小配置太小了嘛

还不清楚，但是应该不是这个问题，毕竟这个数组大小只有8个字节，栈我好像搞得挺大，应该还是访问权限的问题

eric2013

方便的话，稍贴点代码看下

死不低头

eric2013 发表于 2025-6-20 13:28
方便的话，稍贴点代码看下

简单点说就是4步，
1，找到需要提取uint8_t buff[256]数组的元素的起始地址s和个数n；
2，算出来最少用uint32_t 数组m个才能装得下，为了后面操作避免溢出加了个1，m=(n>>2)+1；
3，声明一个数组uint32_t temp[m],这里就不对了；
4，然后用memcpy(temp,&buff,n)。跑这个就进内存异常中断。

死不低头

这帖子还能自动加工文字？最后一句memcpy(temp,&buff【s】,n)

spi-sd

我怎么感觉memcpy(temp,&buff,n)，&buff这样写会有问题?还是也可以有这种写法?

spi-sd

memcpy(temp,&buff,n)，可以这样写吗？我还不知道&buff

Penguins

死不低头 发表于 2025-6-20 17:09
简单点说就是4步，
1，找到需要提取uint8_t buff[256]数组的元素的起始地址s和个数n；
2，算出来最少用 ...

第 3 步声明变长数组有啥不对？报硬件异常了吗？

死不低头

Penguins 发表于 2025-6-20 20:34
第 3 步声明变长数组有啥不对？报硬件异常了吗？

这一步异常了，但是没进异常中断，我看当时情况是数组长度为2，temp[2]，temp[0]是正常的，temp[1]里面数据不对，下面一句memcpy就内存错误异常了

way2888

声明一个数组uint32_t temp[m],m是变化的,你这样能编译通过就神奇了

Penguins

死不低头 发表于 2025-6-20 20:39
这一步异常了，但是没进异常中断，我看当时情况是数组长度为2，temp[2]，temp[0]是正常的，temp[1]里面数 ...

C 语言局部变量不指定初始值本来就不保证为 0，何来 temp[1] 数据不对一说？

Penguins

way2888 发表于 2025-6-20 20:41
声明一个数组uint32_t temp[m],m是变化的,你这样能编译通过就神奇了

C99 标准支持变长数组，CubeMX 生成的工程默认就是 C99，编译通过很正常。但是要注意变长数组是放在栈上的，栈空间过小可能导致越界，且不会引起编译警告或错误。

死不低头

spi-sd 发表于 2025-6-20 20:18
memcpy(temp,&buff,n)，可以这样写吗？我还不知道&buff

memcpy(temp,&buff【s】,n)，后面不是补充了？你看第4步，被论坛给自动优化掉了，我还编辑了几次

死不低头

way2888 发表于 2025-6-20 20:41
声明一个数组uint32_t temp[m],m是变化的,你这样能编译通过就神奇了

不止能编译通过，还是从HC32F4A0工程跑了两周的程序呢

heky_control

直接看汇编比较准

darthmike

死不低头 发表于 2025-6-21 00:14
不止能编译通过，还是从HC32F4A0工程跑了两周的程序呢

说明你这个程序是用的c99标准

死不低头

darthmike 发表于 2025-6-21 11:56
说明你这个程序是用的c99标准

是的，我记得我之前改过勾选C11标准，然后编译一堆错的，都在官方库函数里，马上又换回C99了