这几天对项目的架构做了一个很大的更改, 然后经过艰难的编译不通过修改, 终于编译通过了, 这时候出现了一个奇怪的问题: 通过串口dma发出来的二进制数据全部为0x00, 过几秒钟值才会刷新一次, 然后又卡在这个值几秒钟一直发. 单步调试明明dma对应数组的值已经变成目标值, 但发出去的就是不对, 中断和阻塞发送都正常. 而几天前未调整过的程序却可以正常dma打印, 排除硬件问题. 于是拿compare工具对代码进行对比, 未发现什么明显的问题, 而且串口部分代码已经几个月没有进行任何改动, 按理来说不应该出现任何问题. 想了几种可能性, 难道是哪个memset什么的写错导致访问不该访问的地方重入了?还是mcu是假的根本没有512k的ram导致溢出了?(但中断发送却正常, 不应该啊)
于是尝试性的将一个一百多k的数组变成1试了一下, 串口果然正常了, 但想了想mcu不应该是假的, 于是将数组变得很大对数组后面的值进行赋值读取发现也是可以的, 而且单步调试明明内存中的值已经按预期改变了. 后来比较.map文件发现了以前的工程和现在工程有个很大的不同, 就是以前的dma数组地址编译完dma内存地址在大数组前面, 所以没出问题, 现在编译完却到了后面, 于是出问题. 就通过__attribute__((at(0x20020000)))直接将大数组扔到了后面, 发现串口正常了.
但疑惑没有解决, 为什么将dma的数组放到后面它的值就很难刷新导致串口发错误的值?各位如果有大ram的f7可以试一下, 通过__attribute__((at))将dma对应的数组扔到后面看看会不会一直不刷新, 这个stm32的bug还是有我知识的盲区?
|