最近在用cmake和GCC开发，发现了一个很严重的问题

发现小华的MCU，使用GCC，只能使用10.3版本的arm-gcc，如果在ubuntu或者mac使用最新的14.2，编译出来的程序很可能会导致MCU死机，根本无法使用，上次开发了个sd卡更新程序的bootloader，我本想开源在github上，使用aciton来自动编译程序，这样看来，也泡汤了，10.3的编译器，是21年的产物，ubuntu和mac的hombrew，都不再提供了，联系小华的技术支持，把能复现问题的源码发给了他们，他们说，目前也不会特意去兼容GCC新的编译器，哎，想换个国产的MCU，感觉好难。

我mac上用的14.2.1一点问题都没有，基本上常用的小华MCU型号都有相应的工程，没有你说的问题，应该是你自己的问题

wubangmi 发表于 2025-3-7 17:20
我mac上用的14.2.1一点问题都没有，基本上常用的小华MCU型号都有相应的工程，没有你说的问题，应该是你自己 ...

同样的代码，换编译器就好了，同样的串口驱动，在移植了rt-rhread时，就是好的，代码就是官方例子的串口轮询例子，单独一个串口只要编译进去，下载到mcu立马死机，而且极难恢复，mcu会无法下载程序，连debug都不可以，您需要代码吗？里面就一个串口轮询代码，14.2编译我是下载的win的交叉编译工具，我明天试试Mac编译的能否运行

为什么不直接用IDE编译呢？

weifeng90 发表于 2025-3-7 19:20
为什么不直接用IDE编译呢？

IDE也会调用交叉编译工具，一样的

wubangmi 发表于 2025-3-7 17:20
我mac上用的14.2.1一点问题都没有，基本上常用的小华MCU型号都有相应的工程，没有你说的问题，应该是你自己 ...

同样的代码，如图，mac上使用14.2编译后，下载到mcu后，mcu死机了，第二次亮红色的，mcu已经无法再下载程序了，这代码在10.3版本的gcc编译后，mcu是正常运行的.
源码开放在github

复制

https://github.com/nczyw/hc32f4a0-bootloader

wubangmi 发表于 2025-3-7 17:20
我mac上用的14.2.1一点问题都没有，基本上常用的小华MCU型号都有相应的工程，没有你说的问题，应该是你自己 ...

退回10.3编译后，mcu就能正常工作了，可以多次重复下载。这问题卡了我一星期，已经很明显是gcc新版本，小华的mcu兼容不了，我有一个版本移植了rt-thead，当时用14.2编译的也是正常的，我是只写了个串口程序才发现这个问题的，你用14.2要小心，应该是编译器有什么优化导致的

这种问题就有点难解决了。
要查的话，需要从汇编代码上来看了

jobszheng 发表于 2025-3-8 09:45
这种问题就有点难解决了。
要查的话，需要从汇编代码上来看了

我有一次成功进入过debug，看到一直在汇编文件中打转，但是可能是假的，因为mcu死了后，是进不去debug的，唯一能正常操作的是读取芯片id，其余的是随缘，一直这样操作，偶尔一次可以让mcu停下来，能下一次正常程序，才能恢复，我把所有异常的程序和二进制和map文件和编译器和源码都发给小华的技术了，不知道他们会不会着手解决新编译器导致的问题，电话里说的应该不会太积极，他们讲他们客户主要集中在keil，gcc编译器他们本来支持就不好，哎

有问题你就查出问题原因啊，指望别人帮你查，你自己要怎么进步？
另外，mcu 开发，我建议使用 arm 官网下载的嵌入式版本的 arm gcc，别下错了 arm pc 用的版本
在 Arm 官方网站的 "GNU Arm Embedded Toolchain Downloads" 页面下载您系统相应版本的 gcc-arm-none-eabi
还有，调试也别指望不靠谱的单步调试，建议用终极调试手段串口打印，不方便用串口就 io 点灯，譬如在汇编阶段

我觉得楼主只是发出来，分享一下他遇到的问题。
为其他人计划使用，或者正在使用的坛友提个醒。
遇到问题固然要自己多努力解决，但发现问题，并转交负责部门人员不正是我们应该做的事情吗？！

我反倒觉得楼上您没有摆正心态，认真阅读楼主的帖子内容。

dukedz 发表于 2025-3-8 14:47
有问题你就查出问题原因啊，指望别人帮你查，你自己要怎么进步？
另外，mcu 开发，我建议使用 arm 官网下载 ...

首先10.3和14.2的编译器gcc-arm-none-eabi的都是官方下载的，其次我说的是新版编译器编译的程序，mcu会死机，根本无法进入调试阶段，还打印信息？点灯？，mcu就只能读取ID了，完全无法下载新程序进去，也不能进入调试模式，我不明白你攻击我的目的是啥，我明明发现了mcu不支持新版编译器的缺陷，并把缺陷反馈给了官方，在论坛发帖，提醒使用新编译器的用户注意这个bug，触发新版编译器这个bug的原因不明。莫名其妙攻击我。

nczywq 发表于 2025-3-9 03:20
首先10.3和14.2的编译器gcc-arm-none-eabi的都是官方下载的，其次我说的是新版编译器编译的程序，mcu会死 ...

抱歉，我不是想攻击你，只是提了一些建议，让您误会了很抱歉

我觉得现在主要的问题是要先解决烧录的问题，确保出了问题还可以烧录

是否可以手动控制 复位 脚，或者 boot 选择脚，让芯片处于可以烧录的模式

只要可以烧录，用串口打印或者 io 点灯一步步查，就可以调试是死在哪里了（启动代码的汇编也可以调试）

也可以用 pyocd 启动 gdb server，然后 gdb 命令行单步调试（有时命令行可能比 gui 靠谱些）

最后想说的是，国产也有不少支持 linux 的 arm mcu，譬如 A*32，它家还有支持 linux 环境的类似 stm32cubemx 的配置工具，可以考虑支持一下

dukedz 发表于 2025-3-9 23:29
抱歉，我不是想攻击你，只是提了一些建议，让您误会了很抱歉

我觉得现在主要的问题是要先解决烧录的问题 ...

烧录不了的，调试模式也不可进入，mcu和死掉一样。只能读取芯片ID，如果能进入gdb，那都不是事儿了，我何必去联系小华技术呢。

nczywq 发表于 2025-3-7 18:54
同样的代码，换编译器就好了，同样的串口驱动，在移植了rt-rhread时，就是好的，代码就是官方例子的串口 ...

我只能证明到这里了,详情请看图片1~5.

按照你的说法，采用的是uart_polling的例程(例程版本是F4A0的v2.3.0)，由于本人板子没有例程的PH13和PH15，故改成了PA08和PA09。

python用的是3.13   ArmGNUToolchain是14.2.rel1   IDE环境是eclipse (2024-12)   操作系统是MacOS  13.7.4

其他配置如图片所示，ArmGNUToolchain、python和Eclipse各个版本我都是从很低的版本一直升上来的。

我想说明的是所有的软件都没有问题，是你的其他方面没有注意到或者配置的问题。

实在不行你可以找代理商或原厂，再不行就直接用keil，那个最方便。

nczywq 发表于 2025-3-7 20:27
退回10.3编译后，mcu就能正常工作了，可以多次重复下载。这问题卡了我一星期，已经很明显是gcc新版本， ...

你不能忽略编译器给你的提示啊，编译器都告诉你了:C Target type hc32f4a0 not recognized.

你应该先把这个问题解决了，不然编译器找不到对应的FALSH算法文件，他可能随便往FLASH塞了些数据。

那不死机就奇怪了。

nczywq 发表于 2025-3-10 09:19
烧录不了的，调试模式也不可进入，mcu和死掉一样。只能读取芯片ID，如果能进入gdb，那都不是事儿了，我何 ...

既然 “烧录不了”，又是怎么做到“退回10.3编译后，mcu就能正常工作了”？

应该是同一个板子吧。还是说烧录不了的板子报废掉，又换了块新的板子？

wubangmi 发表于 2025-3-10 09:36
你不能忽略编译器给你的提示啊，编译器都告诉你了:C Target type hc32f4a0 not recognized.

你应该先把 ...

这个提示是正常时的，指令写错了，我下面改了，异常那张图才是，既然你用的可以，那应该是我cmake给编译器加了什么选项，或者少了什么选项，我过几天验证一下，具体是哪个选项导致的新编译器编译出来有问题，感谢您。

dukedz 发表于 2025-3-10 10:01
既然 “烧录不了”，又是怎么做到“退回10.3编译后，mcu就能正常工作了”？

应该是同一个板子吧。还是说 ...

死掉的mcu，用keil，不断读取芯片ID，下载，debug，三个选项，重复个N次，总有一次可以让mcu停下来，并下入正常程序，mcu就能恢复，就又可以了。

nczywq 发表于 2025-3-12 00:39
这个提示是正常时的，指令写错了，我下面改了，异常那张图才是，既然你用的可以，那应该是我cmake给编译 ...

装个X，截个图给你展示一下Mac下的Vscode+GCC的工程。
vscode/GCC工具链等都是最新的版本。