有一回朋友拿着块正点原子的imx6ull开发板来找我说代码烧进去以后设备树编译也通过了但LED死活不亮屏幕终端上中文全变乱码他几乎怀疑板子本身是坏的。我接过来第一件事不是通电而是翻原理图、查启动日志、确认u-boot到底加载了哪份设备树前后二十分钟把问题定位了。这种情形我遇到太多次了说句实在话绝大多数开发板问题不是板子坏而是“使用流程”没理顺。“开发板使用”这四个字听起来宽泛实际是一条很完整的链路开箱核对、环境搭建、上电连接、编译烧录、调试排障最后把程序固化到板载存储每一步都有讲究。这条链路对MCU类的ESP32-S3、STM32嵌入式Linux类的imx6ull、全志T113、STM32MP157、Radxa RK3588通信模组类的合宙Air202 S6甚至FPGA/SoC类的Zynq、复旦微mfql20基本上都适用差别只在工具链和操作细节。这篇文章就按我自己玩板子、帮人救板的经验把完整流程从头到尾捋一遍。新手可以照着走平时只玩一种板子的人跨平台换板时也能拿这套方法快速上手。1. 拿到板子先别急着通电1.1 先读原理图和丝印把板子认全很多人拿到新板子第一反应是接USB、上电、看灯亮不亮。我建议先忍一忍板子不会因为你晚通电十分钟就跑掉但你要是接错线它可能会直接烧掉。第一步永远是看原理图和板子上的丝印。开发板厂商一般都会公开原理图ESP32官方的esp32-devkitc原理图、正点原子的imx6ull底板原理图、合宙Air202 S6开发板的资料页都可以直接下载到PDF。原理图是排查一切问题的第一手依据哪怕你完全看不懂电路只需要能找到电源引脚、串口引脚、下载模式引脚、复位引脚在哪就已经能解决大半问题。拿合宙Air202 S6开发板举例它核心板引出一排26pin排针很多新手不看丝印直接插杜邦线结果电源引脚接错模块当场冒烟。正确做法是先看板背面的丝印确认每个引脚的功能再用万用表量一下电源脚和地之间是否有异常短路确认无误再接外围设备。这类通信模组开发板的排针电源、地、主串口、调试串口、SIM卡相关引脚往往混在一起单靠颜色猜肯定出事翻原理图或丝印图是最稳的。1.2 分清你手里是哪一类开发板拿到板子以后先给自己一个定位手里这块板子属于哪一类。这个分类决定了你后面用哪套工具链、哪套烧录方法、哪套排障思路。大致可以分四类MCU类开发板比如STM32F103、ESP32-S3、ESP8266单芯片跑固件没有复杂操作系统程序直接烧进Flash上电就跑。嵌入式Linux类开发板比如imx6ull、全志T113、STM32MP157、Radxa Rock 5B这类带BootLoader、Linux内核、根文件系统三层启动流程复杂需要交叉编译。通信模组类开发板比如合宙Air202 S6这种核心价值是提供网络能力一般通过AT指令或SDK跟MCU配合使用调试时重点看串口指令交互。SoC/FPGA类开发板比如Zynq-7100、Xilinx ZU15EGAXU15EG系列、复旦微mfql20这类需要HDL工具链烧录的是bit流、FSBL等流程跟前面几类完全不同。你手里板子的类型直接决定了后面环境搭建、编译烧录的方法。所以这一步不要跳过看板子上的主控丝印再对照官方资料确认型号很多板子型号看着像但其实版本不同外设和启动方式会有差异。1.3 资料收集清单少走冤枉路开箱后建议顺手建一个文件夹把以下几类资料放进去之后的开发会顺畅很多主控芯片的数据手册datasheet和参考手册reference manual。前者看电气特性和引脚定义后者看寄存器和外设。开发板原理图再强调一次这个是必须的。官方SDK、BSP、出厂固件镜像、烧录工具。最好连版本号一起记录很多时候编译报错就是SDK和工具链版本对不上。启动模式说明。很多板子靠拨码开关或跳线选择启动源SD卡、eMMC、USB下载、串口下载不同模式行为完全不同。厂商/社区的FAQ和论坛帖遇到问题先搜比我盲猜快得多。资料看的顺序也有讲究我个人的习惯是先看“快速开始”手册再对照原理图看板子最后才翻芯片参考手册。一上来硬啃几百页英文手册你坚持不了三天。2. 开发环境搭建别混用工具链2.1 MCU类板子以ESP32-S3为例MCU类的开发环境相对简单但选型上还是有讲究。以ESP32-S3开发板为例它是一颗双核LX7处理器主频240MHz带WiFi和蓝牙还有USB Serial/JTAG功能不需要额外接USB转串口芯片就能烧录和打印日志这对新手很友好。ESP32-S3的开发方式主流有三条路Arduino IDE配合espressif的ESP32开发包适合快速验证功能、点灯、传感器采集这类场景五分钟能跑通一个Hello World。乐鑫官方的ESP-IDF功能最全适合做产品级应用但环境搭建稍重需要安装编译工具链和Python依赖还要source export.sh。MicroPython适合逻辑不复杂、对实时性要求不高的场景代码量最小。我的建议是快速验证用Arduino或MicroPython正式做产品用ESP-IDF。Arduino的环境虽然简单但驱动的底层细节被封装掉了做低功耗、自定义协议栈这类功能时会比较吃力。这些环境搭建本身不难真正坑人的是依赖下载速度初次安装ESP32核心包时特别慢建议提前配好代理镜像源不然卡在下载页面一两个小时很正常。2.2 嵌入式Linux板子交叉编译是主线如果你手里的板子是imx6ull、T113、STM32MP157、RK3588这类环境搭建的思路就不一样了重点在于交叉编译工具链和文件系统。交叉编译的意思很简单你的Ubuntu主机性能强、工具齐全但它是x86架构而开发板是ARM架构从x86主机编译出ARM架构的可执行文件就叫交叉编译。具体要做的事大致是装一台Ubuntu版本建议20.04或22.04虚拟机、双系统、WSL2都行关键在于稳定别今天换一个明天换一个。装交叉编译工具链。32位ARM板的用arm-linux-gnueabihf-gcc64位ARM板用aarch64-linux-gnu-gcc。注意用厂商SDK自带的工具链版本不要自作主张装个新版GCC很多时候源码在你当前内核版本下只能用特定版本工具链编译。跑通厂商提供的Buildroot或Yocto或者至少会用他们的编译脚本一键编译内核、设备树、根文件系统。配置网络服务让开发板能跟Ubuntu主机通信为后面的NFS挂载和SSH调试做准备。这里说个很多人会忽略的点你编译内核时用的工具链跟你编译应用层程序用的工具链最好保持一致。同一个工具链编译出来的东西glibc版本、ABI接口都是一致的不会出现“本地能跑板子上段错误”的尴尬情况。2.3 串口终端工具选型影响排障效率做嵌入式开发串口工具几乎是每天都要用的。Windows下我用得比较多的是MobaXterm和XshellLinux下用minicom或PuTTY。这东西看起来不重要但真的很影响效率。我见过不少新手用各种绿色版串口助手日志一多就卡死或者编码识别不对中文全是乱码。MobaXterm这类工具好在会话管理方便串口、SSH、SFTP在一个界面里切来切去而且对UTF-8编码支持比较完善这就是为什么同样是看日志imx6ull板子在屏幕终端显示中文乱码但用MobaXterm连接却显示正常。屏幕终端和串口终端走的是完全不同的链路这个我后面在调试章节详细展开。选终端工具的底线是支持自定义波特率、支持UTF-8/GBK切换、能保存日志到文件。满足这三条基本就够用了。3. 上电与连接先点亮“生命线”3.1 串口连接开发板的生命线MCU板子和嵌入式Linux板子串口都是最重要的调试通道尤其是Linux板子如果串口没有输出后面的启动流程你完全不知道进行到哪一步。串口连接看起来简单其实坑很多USB转TTL模块的TX要接开发板的RXRX接开发板的TX很多新手同性相斥TX接TX自然什么都没输出。GND一定要共地不共地的话信号电平没有参考点表现是偶尔有乱码或完全无反应。电平要对齐3.3V的板子不要用5V的TTL模块直连长期用容易烧引脚。ESP8266就是3.3V电平用5V模块时最好加电平转换。波特率要确认。很多开发板出厂默认是115200但也有74880、57600、9600的例子错了就是满屏乱码。我接好线以后的习惯是先打开串口工具再给板子上电这样能完整看到从BootLoader到内核或固件启动的全过程日志信息量最大。如果板子已经跑起来了再打开串口往往只能看到后半段输出。3.2 网络连接与“开发板挂载Ubuntu”嵌入式Linux开发板调试阶段最提升幸福感的一件事就是把开发板和Ubuntu主机之间的网络打通。所谓“开发板挂载ubuntu”最常见的意思就是开发板通过NFS挂载Ubuntu主机上的目录这样代码、文件系统都在主机上改开发板实时读取省去每次修改都要重新烧写存储介质的麻烦。配置NFS的基本思路是在Ubuntu主机的/etc/exports里声明一个共享目录比如/srv/nfs 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)然后执行exportfs -ra生效。开发板那边执行mount -t nfs 192.168.1.100:/srv/nfs /mnt/nfs如果开发板的根文件系统就是一个NFS目录那甚至可以从网络完全启动系统调试体验跟本地开发没什么区别。另一种理解“挂载”的方式是在Ubuntu主机上用读卡器挂载开发板的SD卡/eMMC镜像直接修改里面的文件。这个在备份和定制系统时特别常用做法是losetup挂载镜像分区或者直接用kpartx映射分区设备我后面固化章节会再提。除了NFSSSH也是Linux开发板必备的。基本流程是确保板子上有sshd服务同一局域网下用ssh root板子IP登录文件传输用scp或sftp。能SSH到板子上干活体验会上一个台阶。3.3 初次上电的检查清单第一次给板子上电不要急着插各种外设先做最小系统验证。我的检查顺序是这样的看电源指示灯是否亮如果供电正常但灯不亮先查供电电压和电源开关。听或闻有没有异常电流过大时电源芯片会发烫有异味赶紧断电。看串口有没有输出如果连BootLoader的log都没有检查串口连接、波特率、启动模式拨码。按一下复位键看输出是否重新开始能重新启动说明主控基本是好的。逐步加外设每次只加一个方便定位问题。这套顺序看起来很基础但真的能帮你省很多时间。我见过很多人把传感器、屏幕、电机全都接上之后才上电结果板子启动异常排查了一圈才发现是某个外设短路拉低了电源电压。3.4 ESP32-CAM的“管理地址”到底怎么找热搜里提到“esp32cam开发板管理地址”这个很多人会误解。ESP32-CAM本身并没有一个固定的管理页面地址它取决于你烧录的固件。常见的两种场景是这样如果烧录的是ESP32官方CameraWebServer示例并选择AP模式手机连上ESP32-CAM发出的WiFi热点浏览器访问192.168.4.1就能进入配置页面。如果让它连接家里路由器STA模式它的IP地址就要去路由器后台看DHCP列表或者用nmap -sn 192.168.1.0/24扫描仔细看MAC地址对应的IP。写代码时也可以主动把IP打印到串口或者用mDNS域名方式访问。所以下次遇到“ESP32-CAM管理地址是多少”这种问题先确认烧的什么固件、跑的什么模式答案自然就有了。固件烧好了却访问不了绝大多数是WiFi没连上而不是地址不对。4. 编译与烧录跑通最小程序4.1 MCU编译与烧录的基本逻辑MCU类板子的编译烧录核心流程可以用一句话概括把源码编译成目标固件再通过调试器或串口把固件写进Flash。以ESP32-CAM或ESP32-S3为例Arduino IDE里选择正确的开发板型号、COM口、Flash大小点上传就完事。但底层逻辑是工具会先把ESP32拉入下载模式通常通过控制DTR/RTS引脚让GPIO0在复位时为低电平然后通过串口用esptool协议把固件写到Flash地址0x1000附近。这里有个很现实的注意事项很多ESP32-CAM板子没有自动下载电路需要手动把IO0拉低再复位否则点上传一直卡在“Connecting”。同理STM32板子的原理也是一套只是工具变成了ST-LINK配合STM32CubeProgrammer。我建议拿到MCU板子的第一件事是编译并烧录官方示例里的Blink或Hello World不是跑自己的业务逻辑。这样能把“开发环境没问题、串口工具没问题、烧录链路没问题”三个前提一次性验证掉。4.2 设备树是什么正点原子imx6ull的dtb案例嵌入式Linux板子和MCU有一个明显不同就是会碰到设备树。像imx6ull、T113、RK3588这些板子都是通过设备树来描述硬件资源的比如LED接在哪个GPIO、屏幕的时序参数、SD卡挂在哪个控制器下面。设备树的源码是.dts文件编译产物是.dtb二进制文件流程是make ARCHarm imx6ull-alientek-emmc.dtb或者手动用dtc工具dtc -I dts -O dtb -o myboard.dtb myboard.dts正点原子Alpha开发板编译出imx6ull-alientek-emmc.dtb之后LED不亮不要急着怀疑硬件先查三件事新编译的dtb是否真的被u-boot加载了。很多板子u-boot下面有uEnv.txt或者extlinux/extlinux.conf里面指定了设备树路径你把dtb编译了但没替换到对应路径板子加载的还是旧文件。设备树里LED节点和实际引脚是否对应GPIO号、引脚mux是否正确。设备树配置错误最常见的就是GPIO号对不上。内核是否把对应的GPIO子系统驱动编进去了如果驱动没打开设备树里写了节点也白搭。设备树改起来不算难但排错链路比较长从dts源文件到编译再到u-boot加载再到内核驱动解析任何一环断了现象都是“没反应”。4.3 Linux整机烧录的几种方式嵌入式Linux板子的烧录按存储介质不同大致分三类SD卡烧录最简单把整盘镜像用dd ifxxx.img of/dev/sdX bs1M statusprogress写进SD卡。注意写的是/dev/sdX不是/dev/sdX1分区整盘写错会覆盖分区表。eMMC烧录板子通常支持USB下载模式或fastboot。比如瑞芯微的RK DevTool、全志的PhoenixSuit、ST官方STM32CubeProgrammer都是图形化工具选择对应的loader和镜像文件一键烧录。网络烧录u-boot里用tftp或nfs加载内核和rootfs适合调试阶段反复测试不用老是插拔存储卡。STM32MP157比较特殊它是MPU烧录方式更接近嵌入式Linux板子用STM32CubeProgrammer配合flashlayout文件烧写eMMC或SD卡而不是像普通STM32单片机那样用ST-LINK只烧一个固件。如果你第一次碰这颗芯片别套用以前的STM32经验流程差别很大。4.4 烧录时的几个关键检查点烧录失败是高频问题按我的经验90%的烧录失败出在这几个地方USB线只能充电不能传数据换一根线立刻解决这个坑几乎人人都踩过。没有安装USB驱动电脑识别不到设备烧录工具自然报错。常见的CH340/CP2102/FT232驱动提前装好。没有进入下载模式很多板子需要按住BOOT键再上电或者拨码开关选择下载启动否则工具连接不上。镜像文件损坏或格式不对尤其是从网盘下载的镜像压缩包没解压完整就用来烧录烧完启动不了。烧录中途拔线导致存储写入一半启动时卡在BootLoader或直接黑屏。烧录过程不要手贱等工具提示成功再断电。5. 调试与排障从现象反推原因5.1 imx6ull屏幕终端中文乱码MobaXterm却正常这是一个非常典型的案例值得展开讲。现象是imx6ull开发板在屏幕终端比如HDMI或LCD显示的控制台上显示中文时全是乱码但同一块板子用MobaXterm通过串口连接中文显示却完全正常。很多人这时候会猜是系统locale问题但忽略了一个关键点屏幕终端和串口终端根本走的是不同链路。串口终端输出的是纯文本流MobaXterm在PC端做解码显示它只要收到UTF-8字节就能正确渲染成中文所以显示正常。而屏幕终端是开发板自己渲染需要Linux内核的帧缓冲控制台或者终端模拟器提供中文字体支持。如果内核里的fbcon没有配置中文字体或者终端环境缺少中文字库中文字符就只能显示成方块和乱码。排查步骤可以这样走先在板子上执行locale看系统locale是C/POSIX还是zh_CN.UTF-8。如果locale不对在/etc/environment里加LANGzh_CN.UTF-8重新登录生效。确认屏幕终端确实在用UTF-8编码。有些板子默认终端编码被设置成GBK输出UTF-8字节自然乱码。如果是图形界面缺少中文字体安装fonts-wqy-zenhei这类中文字体包刷新字体缓存。如果只是内核启动日志乱码基本可以断定是fbcon没有正确加载中文字体这不影响系统工作可以暂时不管或换用英文启动信息。MobaXterm正常反而是个很好的线索它说明系统本身输出的编码是对的问题出在显示环节而不是应用层数据损坏。5.2 ESP8266与STM32通信的典型坑ESP8266与STM32通信是物联网开发的经典组合STM32跑逻辑ESP8266做WiFi透传或AT指令控制。看起来简单实际踩坑很多。ESP8266出厂一般是AT固件通过串口收AT指令。STM32发AT\r\n如果模块回OK说明通信链路正常。接下来设置WiFi连接ATCWMODE1 ATCWJAP你的SSID,你的密码但常见的坑有这些电平不匹配。ESP8266的IO是3.3V有些STM32板子的TX是5V电平直连会“超标”轻则通信不稳定重则烧引脚。稳妥做法是加电平转换模块或者用3.3V供电的STM32板子。共地问题。STM32和ESP8266各自的电源不共地串口信号就没有参考点表现就是收到一堆乱码。波特率不匹配。ESP8266默认115200没毛病但有些模块固件不一样实际跑在9600或者上电瞬间BootLoader会以74880输出一段信息一看到乱码就慌其实只是那段引导日志的波特率特殊。发送节奏问题。AT指令不是发完就行的要等模块返回结果再发下一条。一次把ATCWMODE1和ATCWJAP...连发出去模块还没来得及处理经常丢指令。踩过这些坑之后我养成了一个习惯任何板子和模块通信前先用USB转TTL接电脑串口助手手动验证一遍指令交互确认模块工作正常、指令格式正确再让MCU去发。这样能很清晰地把问题隔离在“模块侧”还是“MCU代码侧”。5.3 常见问题速查表把上面这些内容整理成速查表遇到问题先对着查一遍。现象可能原因处理思路上电完全没反应无灯无log电源没供上、开关没开、启动模式错先查电压电流再看BOOT引脚、电源灯串口全是乱码波特率不对、TX/RX接反、没共地、电平不匹配逐个排查波特率、接线、共地、电平转换串口有输出但键盘无效终端工具没发送换行符、系统卡死检查串口工具发送设置确认系统是否hang住屏幕终端中文乱码但MobaXterm正常locale或字体缺失、终端编码不对设置LANG、装中文字体、检查终端编码能ping通但SSH连不上sshd没启动、防火墙拦截、root登录被禁启动ssh服务、配置sshd_config、检查防火墙NFS挂载卡住或权限拒绝exports配置错、没加no_root_squash、服务端没导出检查/etc/exports、exportfs -ra、mount参数WiFi连不上频段不匹配5G/2.4G、密码错、国家码限制改用2.4G网络、核对密码、设置正确国家码烧录工具连不上设备USB驱动没装、USB线只能充电、没进下载模式装驱动、换数据线、手动进入下载模式编译报找不到头文件工具链不对、环境变量没配置、库版本不匹配使用厂商SDK工具链检查PATH和依赖库设备树编译了但外设不生效u-boot没加载新dtb、设备树节点配置错、内核驱动没开核对u-boot配置文件、检查gpio/pinmux、确认内核config这张表是基于大量实际项目沉淀的不能说覆盖所有情况但覆盖了八成新手会遇到的问题。出问题的时候先别急着怀疑板子损坏按照“供电→串口→启动日志→驱动→应用”的顺序逐层排查基本都能找到答案。6. 从“跑通”到“落地”6.1 把程序固化到板载存储开机自动跑调试阶段用NFS挂载、用串口敲命令都无所谓但最终产品形态肯定是要独立运行的这一步就涉及固化。MCU类板子比较简单程序烧进Flash就叫固化问题是开机自启。ESP32-S3跑MicroPython的话把代码命名为main.py放到根目录上电自动执行。跑ESP-IDF的话把编译出的app bin烧录到指定flash地址启动时bootloader会自动跳转。嵌入式Linux板子复杂一些。调试阶段你可能把内核放在SD卡、rootfs挂载在NFS生产环境要改成从eMMC启动rootfs也得放进eMMC。一般做法是先把整个系统做成镜像用dd或厂商工具烧进eMMC然后设置u-boot环境变量的bootcmd从eMMC加载内核。开机自启的逻辑也要确认。应用层程序可以扔进/etc/rc.local也可以写systemd服务[Unit] Descriptionmy app Afternetwork.target [Service] ExecStart/usr/bin/my_app Restartalways [Install] WantedBymulti-user.target两类板子固化之后的验证方式一样断电重启观察串口或屏幕日志确认程序自动启动、功能正常。6.2 备份系统记录版本防止“回不去”开发板越玩越深入之后最怕的就是改坏了回不去。我个人的做法是每个阶段做一次完整备份并记录版本信息。备份SD卡系统最简单的方法还是dd把整张卡镜像出来dd if/dev/sdX ofbackup_$(date %Y%m%d).img bs1M statusprogress镜像文件比较大但相比重新搭环境的成本占点硬盘空间可以接受。eMMC的备份要麻烦一些通常用板子自带工具或u-boot里的ums功能把eMMC模拟成USB存储设备再在PC端dd出来。版本管理不只是代码还包括SDK版本、工具链版本、内核配置文件、设备树源码、根文件系统的制作脚本。我习惯在每个项目的README里写清楚这些信息不然三个月后你自己回来都看不懂当时的编译环境。6.3 换一种板子也能快速上手的通用套路最后说说跨平台怎么上手。你手里的板子可能是Zynq-7100、AXU15EG、复旦微mfql20这类FPGA/SoC也可能是带NPU的AI板子跟普通MCU/Linux开发板的套路会有差异但核心思维是一致的先读文档、再最小系统验证、再逐步扩展。FPGA/SoC类板子的特殊之处在于要先用Vivado或厂商的工具链综合出硬件工程生成bit流和FSBL再在SDK里写ARM侧代码启动时先加载FPGA配置再由ARM引导Linux。复旦微mfql20这类国产FPGA工具链和流程会有些差别但整体思路类似。带NPU的板子比如瑞芯微RK3588系列Radxa Rock 5B这类或者AI语音开发板还要多一步把训练好的模型转换成芯片厂商的模型格式比如rknn、kmodel然后在推理框架里调用。这又多了一条“模型转换-精度验证-性能调优”的链路但你会发现排障的逻辑还是那一套先跑通官方demo确认流程再替换自己的模型和数据。说句掏心窝的话做开发板最忌讳的就是“拿到就开始搞”没有把板子的类型、启动流程、资料体系搞清楚后面每一步都在给自己挖坑。养成先读文档、先跑官方示例、先最小化验证的习惯绝大多数问题在你还没踩进去之前就能避掉。这套流程我用了很多年从最早的STM32到现在各种异构SoC每次换新板子都靠它节省时间。尤其是“串口先有log再谈其他”这条原则救了我无数次建议你也试试。