在正点原子教程异构通信篇,视频教程在加载CubeIDE生成的elf文件这部分内容时,开发板报错如下:
以下是我个人解决问题时的经过,建议大家过一遍我的流程,或许问题是其中的某一步。
一、驱动编译检查
打开根目录/sys/class/remoteproc文件下,发现没有remoteproc0子文件,在debug文件夹下也没有。百度无果,晚上技术客服也没在线。反复检查了教程文档和视频,没有漏哪一步,对了一遍视频,又对了一遍文档,初步估计是内核驱动的问题。
首先是检查了文档提到的内核中各种相关的驱动,图形界面逐个查看,都有选中编译。.config文件也打开逐个看,也都有选中。
二、外设使能检查
于是又往内核启动信息找。在内核启动时看到ipcc已经启动了,说明内核驱动编译没问题,这时候就应该是驱动是否成功加载的问题了。
在根据教程创建的stm32mp157d-atk.dts设备树中,每个引用了的头文件都检查了一遍,和&m4_rproc节点有关的status属性都是disable,也就是都没有开起该节点。
在stm32mp157d-atk.dtsi文件中能够找到
表示ipcc节点是开启的,也验证了在内核启动时打印的信息。
教程文档中提到要我们后续去使能这些节点来开启外设,
但是文档并没有提到如何开启,那么问题应该就是在这了。
三、开启设备树节点
在网上翻阅,终于有幸找到了一篇文章:
&m4_rproc {
memory-region = <&retram>, <&mcuram>, <&mcuram2>, <&vdev0vring0>,
<&vdev0vring1>, <&vdev0buffer>;
mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>;
mbox-names = "vq0", "vq1", "shutdown";
interrupt-parent = <&exti>;
interrupts = <68 1>;
interrupt-names = "wdg";
wakeup-source;
recovery;
status = "okay";
};
博主在文中提到有一个设备树下默认添加了使能节点,但是我的设备树列表中并没有这个文件。
于是我在内核中全局搜索m4_rproc,在stm32mp15xx-dkx.dtsi和stm32mp15xx-edx.dtsi文件下都找到了&m4_rproc的开启节点:
&m4_rproc {
memory-region = <&retram>, <&mcuram>, <&mcuram2>, <&vdev0vring0>,
<&vdev0vring1>, <&vdev0buffer>;
mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>;
mbox-names = "vq0", "vq1", "shutdown";
interrupt-parent = <&exti>;
interrupts = <68 1>;
wakeup-source;
status = "okay";
};
两个文件中的节点信息是一样的,与上文提到的博主相比,少了看门狗的中断部分配置。建议大家选择自己内核中的代码,这样可以减少版本匹配的问题。
把节点信息添加到stm32mp157d-atk.dts设备树下,这个根据自己的开发板创建的设备树来。
编译设备树,复制到tftp挂载目录,重启开发板。
四、测试与结论
内核启动信息中多了一行:
stm32-rproc已经正常启动。
可以看到目录/sys/class/remoteproc下已经有了教程中的文件夹remoteproc0,
此时按照教程加载M4核要加载的文件,
可以看到已经正常启动M4核并且执行了文件。
这里提一下,MDK工程生成的是axf文件,CubeIDE生成的是elf文件,加载后可以进入remoteproc0文件夹下,可以查看对应的信息。
至此问题解决,不知道是我看漏了教程还是之前的工程设置的不对。对当下的问题来说,确实是使能了设备树节点就能够正常执行了,写下这篇文章主要是学习记录,并且希望能够帮助遇到和我同样问题的读者。谢谢