如果是使用的STM32F4的话，RDP2 是不可逆的，是不能回退的。 如果有自己写的升级程序，那么通过它是可以升级，也就是自己定义升级方式。
这样子太麻烦了，不如原生支持来的便利，而且 arm gcc 这个编译器也真的有点老了，newlib 相比 picolib 在 stm32 上使用体验差的有点多
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 };
估算一下速度吧。 接收数据的速度是否合适，处理的时候数据是否能足够正确接收完成？ 处理数据的时候，这些数据是否由于DMA工作时被覆盖掉？ 通常速度设计好，基本上就能得到正常数据了。
不同STM32型号的工程移植，移植过程或快或慢，跟芯片的差异大小、开发者对工程代码的熟悉 程度以及什么类型的外设库密不可分。移植过程中出现些问题也属正常，做些适配、调整动作在所难免。 这里简单聊几点供参考： 首先主要硬件上的差异，外设的多寡、管脚安排差异。 软件代码方面，不建议在老工程上缝缝补补，建议直接创建新工程，把必要的应用代码再次添加进来， 配置好合适工程包含路径。重建工程可以最大程度消除时钟系统、中断配置、DMA安排方面导致的问题。 代码方面，优先处理因外设有无差异而导致的代码问题； 重点处理因系统时钟差异需要调整外设运行快慢有关的配置，这点如果使用cubeMx进行配置基本可以图形化完成； 再就是内存布局方面的问题，比方调整链接脚本，调整指定地址； 还有就是一些宏开关定义，可能是来着库，也可能是自己定义的，因一时忘了相关宏定义导致运行不正常； 因主频快慢差异导致中断、DMA，尤其多中断、多DMA应用时可能因时序方面问题导致些莫名其妙 的问题，这类问题比较隐蔽而颇具细节，可能需要我们反复测试、细心比较琢磨做适当调整后加以解决。 比方位宽问题、对齐问题、标志判断问题、资源竞争。。。。这个时候，我们听得最多的一句就是，同样代码A芯 片好好的，换到B芯片就不行，潜台词往往是想说B芯片是不是有问题？
STM32L4系列的IWDG和WWDG在调试状态下的计数动作是可以单独控制的， 由DBGMCU_APB1FZR1寄存器的第11位和第12位控制。 相应库函数有： __HAL_DBGMCU_FREEZE_WWDG(); __HAL_DBGMCU_FREEZE_IWDG() ; 运行上面代码后，APB1FZR1寄存器的第11位和第12位会被置1，你可以通过SFR寄存器查看确认。 此后，在调试状态下当CPU停止执行指令时看门狗也会停止计数； 你似乎在说，只是调用了__HAL_DBGMCU_FREEZE_IWDG() ;但在CPU暂停执行 指令时WWDG也受到了影响，若是这样的话，你可以确认下DBGMCU_APB1FZR1寄存器的第11位是否也 被置1了，若该位是1，此时你可以使用__HAL_DBGMCU_UNFREEZE_WWDG();将WWDG控制位清零。 我这边实际验证过了，是可以单独控制的。
STM32最初的产品里的启动是靠 boot0 和 boot1 引脚。 随后的产品由于功能增加，多数都保留一个BOOT0引脚和optionbyte 组合方式，具体可以参考手册中关于boot mode 章节。 从datasheet 的引脚描述上也能查到是否取消boot1 引脚了。 具体几种模式需要结合参考手册来看。
.png)
