关于STM32CubeMonitor
采集数据并显示波形
打开后官方提供了一个Basic Flow给我们使用,通过Deploy后打开Dashboard可以看到我们流程生成的程序
在C语言里一种有效组织数据的方式就是结构体,除了储存多种类型的数据外,结构体也是使用一个协议的数据格式最好的办法。这样做还有一个好处就是上位机采用同样的结构体即可通信,在代码层面的移植相当容易。例如
1 | typedef struct{ |
然而有个问题,结构体内部的变量并不是紧密的排在一起,他们中间默认是有空隙的。在上面的代码中sizeof(data_t)
的值并不是4+4+1+4,而是在char c
后面增加了三个字节的空位。这就是内存对齐的问题,本质的原因是硬件上为了减少访问次数,通常会将变量按照4字节对齐。
通俗一点的解释办法,这个原则就是要求单个变量不能跨4字节(当然双精度对于这个原则不适用,但对于四字节及四字节以下的变量,这个原则却是正确的)。那么有没有变量连续储存的结构体呢?由于内存对齐实际上是编译器的优化,而不是硬件的强制要求,所以我们可以配置编译器让它在以牺牲访问次数的代价来换取这种对齐模式。参照编译器手册,我们可以利用#pragma pack(1)
来完成或者在struct前加__PACKED
串口是一种直接接收串行数据的方法,而通常固定数据帧的结构为多个字节,在处理的时候实际上是针对整帧。因此需要通过某种方法将串行数据转换为相当于同一时刻连续出现的数据处理。评定这种转换方法的优劣有以下方面
实际上,在STM32的串口中,我们接收数据通常会采用以下两种方法
IDA, gdb & pwndbg, checksec, pwntools, LibcSearcher
拿到程序后用checksec看,64位ELF,发现没有主程序canary,NX以及ALSR
1 | [*] '/home/ctf/pwn/pwn1' |
独立看门狗(IWDG):通常检测硬件导致的运行出错,独立时钟运行
窗口看门狗(WWDG):通常检测软件漏洞导致的死机死循环,早喂狗晚喂狗都会复位,复位前可产生中断以便保存数据
如何喂狗
正确使用看门狗定时器,但是它并不像重新载入计数器那样简单(通常被称为喂狗或者踢狗)。在其系统中运行看门狗定时器时,开发人员必须仔细选择看门狗的超时时间,以便看门狗在发生故障的系统可以执行任何不可逆转的恶意动作之前进行干预。
在简单的应用中,特别是没有使用RTOS,开发人员通常会从主循环(main loop)中提供看门狗。该方法仅需要配置适当的初始计数器值,它可以简单地选择任何超过整个主循环最坏的执行时间的值,至少有一个计时器周期。这通常是一个非常有效的方法,虽然有一些系统需要立即恢复,但更多系统只需要确保它们不会被无限期地挂起,这一方法能很好的实现之一目的。
现象:使用CubeMX多次Generate Code发现串口初始化出现问题,DMA的CR寄存器除了中断位和使能位其他配置未能写入。调试时发现似乎写入寄存器CR时无效。此问题在仿真情况下不会发生
原因:在先配置UART后Generate Code回头再修改DMA配置,第二次Generate Code后会出现该问题。MX_DMA_Init()初始化函数中负责启动DMA2的时钟,而UART初始化里面也包含了部分DMA2的初始化配置。观察例程可判断正确顺序应该是先MX_DMA_Init()再MX_USART1_UART_Init(),但是在这种情况下,CubeMX的MX_USART1_UART_Init()和MX_DMA_Init()的顺序就会按照Generate Code的顺序。个人推测根本原因应该是在这种顺序下,DMA的时钟未启动而提前写入配置导致配置丢失。参见这篇文章。
解决方案:一定可行的办法是一次配置重建整个项目。在不推倒重来的前提下,可以在CubeMX中取消勾选UART和DMA,然后Generate Code,再按照原先配置勾选UART和DMA然后再Generate Code即可。或者暴力修改.ioc文件中的ProjectManager.functionlistsort,调换UART和DMA的顺序。在Project Manager下的Advanced Setting里面可以看到顺序。
现象:打开调试/仿真Command窗口出现“*** error 65: access violation at 0x40021000 : no ‘read’ permission”,程序停在了system_stm32f10x.c中的一行
原因:该仿真器对只保证CMSIS兼容性,并没有对STM32进行专门配置
解决方案:修改仿真器/调试器加载的DLL,如图