先保证基于内部HSI时钟作为系统时钟源，让程序跑起来。 然后，再尝试使用HSE，HSE就是保证它能正常运行起来，主要是调节 那两个负载电容，结合厂家的晶振参数来调。按理，即使HSE跑 不起来，也不至于程序不运行啊，它会基于HSI来运行代码，或许时序方面有 问题，不会完全不工作。
从你给出的配置来看，数据长度9位，即按16位接收没有问题。 DMA配置没看出明显问题，UART的中断响应也使能了。 你目前使能的空闲中断，鉴于你的情况，是否需要确认UART真正工作起来了。
这样子太麻烦了，不如原生支持来的便利，而且 arm gcc 这个编译器也真的有点老了，newlib 相比 picolib 在 stm32 上使用体验差的有点多
如果是使用的STM32F4的话，RDP2 是不可逆的，是不能回退的。 如果有自己写的升级程序，那么通过它是可以升级，也就是自己定义升级方式。
古代是事情了，才输出5个很简单的，用定时器级联模式或者定时器中断都可以，甚至DMA加定时器也可以。我用STM32F103试过，可以用几个定时器加12个DMA通道，刚好可以输出12路可梯形加减速的脉冲，数量精确可控，但是安全性不高，DM有可能崩，另外就是103计算能力差，12路脉冲需要变速需要大量计算，所以频率上不去，20K以下频率稳定，25K以上就有问题，当然这是12路脉冲同时启动的情况，一般没这么极端
const uint8_t Plaintext = { 0x6b, 0xc1, 0xbe, 0xe2, 0x2e, 0x40, 0x9f, 0x96, 0xe9, 0x3d, 0x7e, 0x11, 0x73, 0x93, 0x17, 0x2a, 0xae, 0x2d, 0x8a, 0x57, 0x1e, 0x03, 0xac, 0x9c, 0x9e, 0xb7, 0x6f, 0xac, 0x45, 0xaf, 0x8e, 0x51, 0x30, 0xc8, 0x1c, 0x46, 0xa3, 0x5c, 0xe4, 0x11, 0xe5, 0xfb, 0xc1, 0x19, 0x1a, 0x0a, 0x52, 0xef, 0xf6, 0x9f, 0x24, 0x45, 0xdf, 0x4f, 0x9b, 0x17, 0xad, 0x2b, 0x41, 0x7b, 0xe6, 0x6c, 0x37, 0x10 }; uint8_t Key[CRL_AES256_KEY] = { 0x60, 0x3d, 0xeb, 0x10, 0x15, 0xca, 0x71, 0xbe, 0x2b, 0x73, 0xae, 0xf0, 0x85, 0x7d, 0x77, 0x81, 0x1f, 0x35, 0x2c, 0x07, 0x3b, 0x61, 0x08, 0xd7, 0x2d, 0x98, 0x10, 0xa3, 0x09, 0x14, 0xdf, 0xf4, }; const uint8_t Expected_Ciphertext = { 0xf3, 0xee, 0xd1, 0xbd, 0xb5, 0xd2, 0xa0, 0x3c, 0x06, 0x4b, 0x5a, 0x7e, 0x3d, 0xb1, 0x81, 0xf8, 0x59, 0x1c, 0xcb, 0x10, 0xd4, 0x10, 0xed, 0x26, 0xdc, 0x5b, 0xa7, 0x4a, 0x31, 0x36, 0x28, 0x70, 0xb6, 0xed, 0x21, 0xb9, 0x9c, 0xa6, 0xf4, 0xf9, 0xf1, 0x53, 0xe7, 0xb1, 0xbe, 0xaf, 0xed, 0x1d, 0x23, 0x30, 0x4b, 0x7a, 0x39, 0xf9, 0xf3, 0xff, 0x06, 0x7d, 0x8d, 0x8f, 0x9e, 0x24, 0xec, 0xc7 };
微信公众号
手机版
.png)
