STM32F407ZET6用USB烧录，之前批次的可以，最新批次的不行，重要紧迫，请加急处理。

你用STLINK连接后通过STM32CubeProgrammer看看，到底芯片是否已经读保护。如果不是2级保护的话，即使用你手头的第三方烧录器也应该可以查看选项字节或对选项字节进行编程的。另外，使用STM32CubeProgrammer也可以对芯片基于串口烧录。

从描述现象上看，读保护被使能，但是J-LINK确能正常烧录，有点矛盾。 而那个中文版的烧录器的LOG显示步骤中有擦除芯片的步骤，不应该再提示有读保护。 所以建议使用官方的ST-LINK+STM32CubeProgramme验证一下，毕竟官方的工具会完善一点。而且也支持串口烧录功能。

STM32CubeProgrammer也能读出信息，用我们那个usb转串口电路下载就会把芯片读保护锁起来，然后就STM32CubeProgrammer就连不上，但是锁起来后只要用flash loader解除读保护，把我们电路上RESET那里断开，BOOT0置1，也能用usb下载。就是说RESET和BOOT0这两个烧录信号，对这个批次的芯片不起作用。

1,本人遇到相同问题。 1.1，和博主的error log 相同。 2，我使用STM32 ST-LINK Utility, （SWD方式连接）下载Hex文件 是可以的烧录成功的。 3，我使用uVison, SWD方式连接,下载Hex文件 也是可以的烧录成功的。 4，目前问题就是，使用ISP方式，下载不成功，报如下error log. 5，我使用DFU方式烧录可以成功，但是起动不成功。。这也是一个大问题，因为我最终使用dfu image, 用Python 编程序。 ======================= error log: 开始连接...5, 接收到:79 1F 在串口COM8连接成功@9600bps，耗时1062毫秒 芯片内BootLoader版本号：3.1 芯片PID：00000413 STM32F40xx_41xx 芯片已设置读保护 第1266毫秒，已准备好 开始编程芯片，共需写入1KB,耗时1281毫秒 调试信息：-4 STM_WriteMemory 写入出错在0KB,进度0%,耗时1328毫秒

读一下烧录的内容，看看与正常运行的有什么区别，包括option byte。

程序烧写，建议还是使用官方的软件。

STM32F407VET6遇到同样的问题，该怎么解决呀？？？急急急 一开始还以为芯片是假的，后来在立创商城上买的也是一样！

如同小伙伴说的，用官方的ST-LINK+CubeProgrammer 软件连接试试，可以读出内部bootloader 版本号，对照应用笔记看看是不是一样的。 另外注意应用板上的晶振要争取，震荡频率也要准确一点。此外，启动boot loader时也要注意其他启动口不要有干扰信号。

我也是22年突然遇到这个问题，f4烧不进去，也感觉是批次问题，现在虽然没有解决这个问题，但是发现了以下两个有意思的现象供参考： 1.选择RTS低电平复位，DTR高电平进Boot loader，注意不是正常的那个选项。点击下载，会出现连接不上，一直显示等待连接，这种情况下其实就是进入了Boot loader但没有复位，然后手动按一下复位，就可以正常下载程序进去！ 2.进一步引申，正常使用DTR低电平复位，RTS高电平进Boot loader，会出现你这样的情况，然后什么也不动，切换为RTS低电平复位，DTR高电平进Boot loader，再点下载，就可以成功下载程序了。 2现象本质上就是通过第一种方案提供一个复位信号，然后再切换到1中的错误选择，只进Boot loader但不复位，就可以正常下载，这似乎提示我们问题与复位有关，进一步研究，发现这回有问题的批次进行烧录时会多次重启通讯，即多次触发复位与进Boot loader，这个现象从你的图一上也可以观察到，你截图的部分已经是第二次走复位+Boot loader流程了，而以前的批次不会有第二次复位+进Boot loader，虽然上述情况的原因不甚明了，但这解释了我的现象2，由于使用错误的RTS低电平复位，DTR高电平进Boot loader，flymcu第二次“尝试”复位并没有成功（第一次必要的复位是来自正确的选项，虽然其烧录失败了），所以不会导致芯片重新出现写保护、读保护等问题，因此可以正常烧录。 那么，问题来到了为什么flymcu在新批次上会尝试多长进行复位？为什么错误的RTS、DTR选项通过手动复位就可以成功，虽然在硬件上看起来操作是没有区别的？以及为什么再次复位后烧录会失败？不知道。可能是由于ch340本身的时序问题，驱动的问题，windows的问题，或者stm32f4里面有暗改或生产差别但没有说明导致的，这个坑可能要由官方来填了。

[md]可以考虑一下最下面我的回答。

研究过了，并没有不同，反复修改选项字节也没有任何区别

[md]推测一个原因，由CH340软件产生的复位会触发读写保护，从而导致需要清除读写保护，清除完flymcu要重新复位，然后又循环起来了。。。

[md]我看到有人说CH340的RTS DTR电平并不是理想的0和3.3，可能是2.5V这样，这也有可能导致无法可靠复位，有人要是用示波器测一测波形，可以发上来分享一下