RT-Thread-【24嵌入式设计大赛】xmagicprobeRT-Thread问答社区

【24嵌入式设计大赛】xmagicprobe

发布于 2024-09-18 23:59:40 浏览：316 订阅该版

[tocm]

# 项目概述
我们做ACPU开发时调试器方面用得最多的功能是配合上位机如openocd读写cpu的各寄存器以及读写内存，其它功能像断点、单步、加载image到内存/sram用着了但用得很少。例如加载image到内存，因ACPU系统普遍带有bootloader的缘故，通常加载都是由bootloader通过网络/usb完成，更方便快捷。

对于MCU开发场景，用得最频繁的除上述功能外，还有一个用得很频繁：配置上位机烧写flash。如果MCU芯片支持串口/usb直接烧写，那么调试器最大作用就ACPU开发场景一样读写cpu寄存器和内存了。

当前MCU性能越来越强，flash和sram资源除了容纳一个CMSIS DAP兼容的固件以外还剩余很多，而且cpu足够均强劲，让我萌生了做一个调试器的想法：它带有CMSIS DAP固件的同时，能集成部分上位机功能。

# 设计思路
当前已有的方案：black magic probe。很明显我需要的功能有点类似black magic probe，但和它又有很多区别，其中最重要两个区别是：
1. CMSIS DAP VS BMP HLA。我仍然保留CMSIS DAP兼容固件，可以充分利用它的上位机生态，而不需要修改上位机程序增加固件的支持
2. 在使用最频繁功能时，需不需要上位机？black magic probe仍然需要gdb，而我想的是脱离上位机需求，等将来MCU资源足够时，完全脱离上位机。

大概流程应该是：移植CherryDAP到RT-Thread，削减openocd并移植到RT-Thread，移植过来的有限d openocd命令以MSH_CMD_EXPORT形式实现成msh下命令

## 移植到板子上的上位机的选型
在资源有限的前提下，只有openocd和urjtag比较合适。但是urjtag开发不太活跃，所以openocd是唯一选择。

## CMSIS DAP选型
我们再看看CMSIS DAP选型，有两个候选：CherryDAP和r_daplink，前者完全是基于裸机环境，后者基>于RT-Thread，由于我需要集成上位机openocd功能，那么一个OS环境还是更合理的。所以我最后选择是以CherryDAP为基础，但参考r_daplink的线程服务框架修改CherryDAP。

注：因flash/sram容量还是有限的，还不够放下完整的openocd，所以只挑选前述最常见的功能实现。相信不久的将来，我们能看到一个有充足资源能放下基本完整的openocd的MCU，那时就是CMSIS DAP + 基本完整的openocd功能啦。

# 系统说明
硬件: HPM5300EVK开发板
软件：RT-Thread + 移植CherryDAP + 移植削减的openocd

# 实现过程
## 移植CherryDAP到RT-Thread
### 先给CherryDAP增加HPM5300EVK的支持

```bash
cp -a projects/hpm5301evklite projects/hpm5300evk
```
比较HPM5361与HPM5301之后发现，HPM5301几乎是HPM5361的丐版，大体上一致的，最高cpu频率不同，所以这导致如下的改动

```c
#define CPU_CLOCK               48000000U      ///< Specifies the CPU Clock in Hz.
```

比较HPM5300EVK与HPM5301EVKLITE板子原理图后发现pin的布局有稍许变化，为方便调试，我用的HPM5300EVK的树莓派接口上的针脚而不是jtag 20pin，所以导致如下的代码变动(注意这是相比于最新的CherryDAP的改动，因为笔者在8月底做完CherryDAP的移植时是基于它4月份的代码，8、9月CherryDAP有大量更新，主要是SPI加速，不过我最后没使用SPI加速，和CherryDAP上游同步后我又再更新本地CherryDAP的hpm5300evk支持)：

DAP_config.h
```c
#if defined(USE_HPM_BOARD_JTAG_GPIO) && (USE_HPM_BOARD_JTAG_GPIO == 1)
    #define PIN_TCK                         IOC_PAD_PA27
    #define PIN_TMS                         IOC_PAD_PA26
    #define PIN_TDI                         IOC_PAD_PA29
    #define PIN_TDO                         IOC_PAD_PA28
#else

```
CMakeLists.txt

```bash
set(CONFIG_USE_HPM_BOARD_JTAG_GPIO 1)

```
移植完毕后发现CherryDAP已经把DLM用去大概95%，几乎没空间给移植的openocd了

![10.jpg](https://oss-club.rt-thread.org/uploads/20240919/5f12cb55321640a8dbf8aa7efa0daafb.jpg)

怎么办？首先想到的是把CDC ACM的支持去掉。然后考察代码后发现CherryDAP为追求性能的极致使用了CherryRB，而且把buffer开得很大，下一步就是把CherryRB的buffer去掉，可参见下面CherryDAP向RT-Thread移植后的结果。

### 把CherryDAP移植到RT-Thread

CherryDAP是基于裸机环境的，整个大流程就是一个while(1)循环，cpu就没多少资源给msh了，所以我们参考r_daplink做法，把DAP命令的执行放一个线程去，并由中断通过mailbox触发，整个框架流程如图：

![8.jpg](https://oss-club.rt-thread.org/uploads/20240919/1c12c3d9e5af1f16cddee8c026559676.jpg)
改变框架的同时，还把CherryDAP中对CherryRB的使用也去掉了，为CherryRB预留的buf占了很多sram资源，既然切换成了mailbox，就没必须用CherryRB啦。

同时还删除了CDC ACM的支持。虽然HPM5361的资源比较丰富，但openocd更大，所以为预留足够的资源把CDC ACM的支持去掉了。

最后的资源使用如图所示：

![9.jpg](https://oss-club.rt-thread.org/uploads/20240919/9d8f58c5e78d20e6e821132d691ef739.jpg)

这仅仅是使用ram的结果，效果很棒，可以看到多用了大概38KB的.text段，换回了大概50KB的DLM空间，给openocd留下了不少资源余地。再考虑到有高达1MB的flash，代码.text段空间倒是基本够了，可能DLM还紧巴巴，移植openocd到RT-Thread时还需要再下功夫

## 削减openocd并移植到RT-Thread
大前提：我们openocd跑在RT-Thread上，它配合的固件就是CMSIS DAP，所以DAPu机CMSIS DAP这一种就可以了，所以什么ftdi、stlink、jlink等等都可以去掉。再考虑openocd和CMSIS DAP是直接通过c语言函数调用交互的，什么socket、libusb也可去掉拉。再考虑什么gdbserver、RTT等也不要，这下就把openocd砍掉一大半了。
首先定下cpu体系结构范围：长远来说我们只支持arm和riscv，其它就不支持啦，当前除x86外就它两最火了，这也是我经常工作的两种cpu平台。短期目标是cortex-m系列cpu。
其次，只支持cpu的halt/resume，cpu寄存器的读。cpu寄存器的写和memory读写就放TODO LIST了。
再次，openocd的交互命令以MSH_CMD_EXPORT形式移植到到msh下。
最后，经过慎重考虑，决定删除jimctl。原因有二：资源问题，HPM5361资源对于运行openocd来说还是比较紧张的；需求问题，配置和使用几乎用不上jimctl这么强大的机制。当然以后资源丰富了移植完整的openocd时，或许会考虑加进jimctl。

到此为止就完了么，no！实现过程发现cmsis dap的上位机还是太复杂了，openocd假设了cmsis dap基于usb的固件，所以cmsis dap和usb部分耦合很紧，所以我又用hpm的gpio实现了bitbang后端，因为openocd中bitbang未和底层传输协议耦合，另外也简单一些。

# 功能演示
## CMSIS DAP固件功能演示
### dmesg

![1.jpg](https://oss-club.rt-thread.org/uploads/20240919/ec0a7296cc9c13f2ae073ae84eefe402.jpg.webp)
可以看到一个名为CherryUSB CMSIS-DAP的高速设备被PC机识别了。

###PC机上openocd的操作
openocd启动
![2.jpg](https://oss-club.rt-thread.org/uploads/20240919/75fb3d27a715f4f74dbae02f9466fcf8.jpg.webp)

telnet下操作
![3.jpg](https://oss-club.rt-thread.org/uploads/20240919/6fd50106d2a7e88d6d221540e5c7f457.jpg)

与此同时，RTT msh上看看

![5.jpg](https://oss-club.rt-thread.org/uploads/20240919/a1670646b67c5c72f3ffe7be1b540b9e.jpg)
可以看到有一个dap的线程，和上面实现过程是对应的：我们有一个dap线程接收名为dap_mb的mailbox发过来的消息并执行

## RT-Thread上msh下openocd命令演示
本来预计能实现cortex-m系列cpu halt/resume和cpu寄存器读取的，但削减并移植openocd到RT-Thread上工作量极大，主要是对openocd流程复杂程度预估不足，所以最后虽然把cortex-m、arm adiv5、DAP、MEMAP相关代码以及openocd中的支撑代码都移植完毕，但最后还是只实现了tapid的读取，如图所示：

![6.jpg](https://oss-club.rt-thread.org/uploads/20240919/5620a78f9aa82f38c3073cab9eb1e00c.jpg)
其实我们每次在用上位机openocd时都会读这个寄存器，这步通了至少说明cortex-m、arm adiv5、DAP相关代码打通了。而cpu halt/resume和cpu寄存器读取需要弄清openocd命令流程，并以MSH_CMD_EXPORT形式移植到msh下，这一步写文章时还未打通，所以大概还有10%的工作未完成。

# 总结
本项目的输出首先是一个可用的CherryDAP固件，不过是基于RT-Thread而不是直接裸机的，可当CMSIS
DAP用。基于RTOS可能有个好处就是CPU不用一直轮讯，空闲时CPU使用率极低，功耗低吧。再次是一个初步的openocd的RT-Thread移植，虽然最后可用命令不多但框架基本打通了。

本项目期间，大部分精力消耗在CherryDAP的资源节省和openocd的削减移植上，尤其在理清openocd内>部的逻辑上耗了大量时间。在发现openocd CMSIS DAP的代码紧耦合后尝试分解后又放弃，那么前期对openocd中cmsis dap的代码阅读就白费了。后续又在调gpio bitbang上耗费时间。事实证明仅靠两个月的周末时间还是不够的，考虑在后续周末继续做，可能需要自己实现精简版的openocd CMSIS DAP的后>端，毕竟gpio bitbang只是临时解决方案。