【深入讨论】今天发现一个有趣的问题 stm32f103数据记录器 usb sdio mmc fatfs

日月当空-2044542

 今天测试自己做的一个串口记录器发现一个有趣的问题，当记录数据达到16M左右的时候，程序就会死在mmc卡多块写的DMA那里等待数据发送完成标志，后来反复的测了几次发现一个诡异的想象。
我是每次上电一次新建一个文件，串口设置为230400.n.8.1，sdio使用4位总线，时钟分频使用5 。记录下的文件通过STM32的USB把记录器作为U盘连接到电脑上显示。先是用串口调试助手满负荷每次发送5.3M左右的测试文件，第一个文件数据不会丢，掉电、上电；第二文件丢掉12K数据（原来我也发现这个，以为是fatfs文件系统在开始往文件里写数据的时候，先去处理文件目录所以会丢失），掉电、上电；第三个文件丢掉头12K数据。掉电上电，第四个文件在发送到13%左右的时候stm32F103会死掉。
当时我以为是因为sdio写文件不够快，导致被串口接收中断占用了太多时间，DMA传输完成标志没有检测到。所以我将sdio改为8位总线，时钟分频使用5。还是用串口调试助手满负荷每次发送5.3M左右的测试文件，第一个文件数据不会丢，掉电、上电；第二文件丢掉12K数据，掉电、上电；第三个文件丢掉头12K数据。掉电上电，第四个文件在发送到13%左右的时候stm32F103会死掉。
当我看到U盘里这么整齐的数据我就有点蒙了，每次都掉电重启的啊，怎么会出现这种情况，后来我想应该是文件长度的问题，所以我弄了个20M左右的文件来测试，发现在发送到77%的时候会死掉。自己算了一下大概也是在16M左右。后来我使用定时发送软件来测试到底是不是由于数据长度的原因导致死机的，定时周期110ms，每次写2048字节，循环发送从00到ff的数据。经过三次测试发现都是在16M左右就会死，我想如果是长度的原因，那应该跟某个数溢出造成的这种异常，我算了一下0xFFFFFF等于16777215（约等于16M），但是奇怪的是定义一个数都是32、16、8位的，从没见过24位的啊。
各位大侠，哪位见多识广，给小弟指点指点，这是为什么呢？这是fatfs文件系统的问题，还是mmc卡的问题，还是sdio，dma的问题呢？

勒布朗

会不会是mmc卡的内存限制

有缘于你

这个没用过,帮顶下

feiante-155820

这个没有弄过，期待高手答案

wkuang

哥们， 给你提几个调试建议：
1、把死机堆栈拿出来看，到底死在哪个函数里，哪个地方有堆栈、或者溢出；
2、做一个函数调用轨迹跟踪，首先定位死机函数，然后再逐个细化，查找问题点。

我们定位踩内存和死机问题都是这样弄的。

Hiker

1,从楼主的问题上感觉像是驱动接口没有配置正确，主要查看CTRL那个接口.
2,高波特率的串口只适用于两通信芯片非常近的电路，如果传输有一定的距离，那么最大波特率保持在115200以下~

日月当空-2044542

后来测试发现好像又不是，因为把同样的程序烧写到另一块板子上，并没有出现相同的情况。使用示波器测试发现写2048字节数据大概需要2.5ms~7.5ms左右，但是应该有时候会超出这个时间，我换成定时保存模式，80ms保存一次数据，并且刷新一次，就会导致文件系统损坏。

日月当空-2044542

回复第 5 楼 于2013-12-27 23:00:48发表:
哥们， 给你提几个调试建议：
1、把死机堆栈拿出来看，到底死在哪个函数里，哪个地方有堆栈、或者溢出；
2、做一个函数调用轨迹跟踪，首先定位死机函数，然后再逐个细化，查找问题点。

我们定位踩内存和死机问题都是这样弄的。 

我使用在线调试，定位到mmc卡多块写函数使用DMA模式的 while (DMA_GetFlagStatus(DMA2_FLAG_TC4) == RESET) {}这里。好像是错过了发送完成标志，但为什么我没搞清楚。
 

wkuang

回复第 8 楼 于2013-12-29 22:33:14发表:
回复第 5 楼 于2013-12-27 23:00:48发表:
哥们， 给你提几个调试建议：
1、把死机堆栈拿出来看，到底死在哪个函数里，哪个地方有堆栈、或者溢出；
2、做一个函数调用轨迹跟踪，首先定位死机函数，然后再逐个细化，查找问题点。

我们定位踩内存和死机问题都是这样弄的。 

我使用在线调试，定位到mmc卡多块写函数使用DMA模式的 while (DMA_GetFlagStatus(DMA2_FLAG_TC4) == RESET) {}这里。好像是错过了发送完成标志，但为什么我没搞清楚。
 
 
 
试试不用DMA，效率虽然低了点，看会不会死机，确定问题点再说
 

dzc2001

 我只前碰到了一个问题，是通过降低sdio时钟解决的。速度高了不行，板子走线不好