|
一个STM32F103VET6的产品,已经好多年,现在还有一些小量出货。因为STM32涨价的原因,今年用GD32F103VET6替换,移植没什么难度,也已经成功出了几批货,但最近这一批,突然出现了问题。程序写入后,板怎么也调不出来,晶振根本就不起振,换晶振,换MCU也不行。
巧在这个产品同一个硬件平台,支持A、B两份程序,简单讲这两个程序是Master和Slave关系,调不出来的是B程序的板。这两个在STM32和GD32两者环境下都是使用过没问题的,尝试写入A程序,能工作,一切正常,这证明了硬件没有问题。当前的环境是MDK 5.17,JLinkV8,反复烧写程序没问题,可以排除工具的原因;A程序的代码量(code 176K)比B程序(code 119K)大,因此也不可能是用小容量芯片冒充大容量芯片的问题。
调整GD32移植时在stm32f10x.h,stm32f10x_flash.c程序中的修改部分,没有用。晶振不起振,不是硬件,而是程序停在HardFault_Handler,死机。Debug看到R14=0xfffffff9, MSP指向的memory是0xacacacac这样的空值,网上关于HardFault调试的技巧没什么用。在startup文件中调整stack/heap大小,也没有用。
想找出B程序是否存在野指针之类的Bug,用削减的方法减少B程序实际的工作,但写入后都是死机。无奈之下另起一个project,重构B程序,将序底层和中间层逐步加入,在main()中,基本的GPIO/RCC初始化后while(1)输出LED on/off,是可以工作的,串口printf也有输出。逐渐增加main()中调用的程序,到一定程度就不行了;追踪这些新加的程序,是一些根本没有被调用到的函数,以及一些A程序、B程序共用的函数。AB两个程序底层和中间层代码是共用的。走不下去,从源程序上无法找出问题。
这个新建的测试project,用的是default的编译配置:Use MicroLib, Optimization=default(无),One ELF Section per Function=true。Optimization改成Level3/optimize for time,也能运行;但去掉"One ELF Section per Function"就不行,这时程序量大得多,从66K code变到119K;去掉MicroLib,启用"#pragma import(__use_no_semihosting) ",也可以运行,但工作程序一增加,还是死机。
回头再用A程序测,启用"One ELF Section per Function",或者去掉Use MicroLib两个配置,都能编译通过,写入STM32的板工作没有问题,但写入GD32的就死机。
感觉和源程序无关,和code size无关,而是与不同程序模块在flash中的定位有关,要分析map文件。这也太困难了,毕竟已经好多年没做 stm32了,现在对单片机也兴趣缺缺。还是选择放弃,产品上退回stm32,好在stm32的价格已经差不多降回来了。
不过还是希望找到原因。不想简单的用国产芯片质量来推脱,但确实这些个替代还有许多诡异的问题。
|
阿莫论坛20周年了!感谢大家的支持与爱护!!
你熬了10碗粥,别人一桶水倒进去,淘走90碗,剩下10碗给你,你看似没亏,其实你那10碗已经没有之前的裹腹了,人家的一桶水换90碗,继续卖。说白了,通货膨胀就是,你的钱是挣来的,他的钱是印来的,掺和在一起,你的钱就贬值了。
|