STM32F407VET6擦除内部flash时报“cannot halt the core”无法进入debug模式的问题

首先仅写入：

发现可以进入debug，而且可以看到内存中确实已经写进去了

运行写入，然后擦除，发现无法进入debug，提示cannot halt the core

但是可以看到已经成功烧录了

这里验证一下写入之后，不写擦除函数，烧录过程是否会擦除数据。

首先打开写入，关闭擦除。

然后关闭写入，关闭擦除

可以看到，内存中依然有数据。所以烧录动作不会擦除所要操作的扇区。

把写入和擦除都关掉看看flash中现在是什么数据

此时可以进入debug

可以发现内存中什么数据也没有。

由于此时的烧录配置是仅擦除扇区，所以猜测应当是刚刚烧录进去的程序已经成功运行了，所以先写入数据之后，又将数据擦除了。下面可以做一个验证。

验证过程：

a、首先仅写入数据

这时进入debug后确认flash中已经成功写入了数据。

b、然后关闭写入，打开擦除

这里由于之前发现不能进debug，所以直接进行烧录

c、最后关闭写入且关闭擦除，进debug看数据是否已经擦除

可以看到此时flash的该扇区中已经没有数据了。

由此我们可以得出结论，虽然适用擦除函数后无法进入debug模式，但是可以烧录，并且烧录后确实已经成功执行了擦除动作。由此可以看到影响进入debug模式的，确实是擦除函数。

为了进一步探究并解决该问题，将库函数搬运到测试程序中执行

首先注释掉后面的程序，发现可以进入debug

这里就发现了，是后面的执行语句导致了这个问题。按照这个思路，我们定位到了这一条语句：

注意到这里有两条语句都是操作了CR寄存器

于是分别注释掉试试看。发现仅运行第一条语句可以进debug，但是仅运行第二条语句时无法进入debug，并且芯片无法再烧录，同样提示cannot halt the core。（解决办法：按住reset按钮，松开瞬间点击烧录）

下面就要查一下文档，看看这几条语句到底是什么

CLEAR_BIT(FLASH->CR, FLASH_CR_PSIZE);

复位编程大小

FLASH->CR |= tmp_psize;

定义编程大小

CLEAR_BIT(FLASH->CR, FLASH_CR_SNB);

复位扇区号

FLASH->CR |= FLASH_CR_SER | (FLASH_SECTOR_7 << FLASH_CR_SNB_Pos);

指定擦除扇区号，擦除方式为扇擦除

下面到了关键的一句

FLASH->CR |= FLASH_CR_STRT;

可以看到FLASH_CR_STRT的定义：

也就是这条语句启动了擦除动作

对于该位的说明如下：

也就是说由软件启动，当BSY清零的时候，该位也清零。

 

查询得知，BSY位在FLASH状态寄存器FLASH_SR中：

由于进debug时报的是cannot halt the core,也就是无法停止。那么我怀疑这里就是BSY一直处于置1的状态，而没有置0。

为什么FLASH操作一直处于忙的状态而导致BSY没有复位呢？

再看一眼程序：

我忽然想到，flash擦除是需要一定时间的，会不会是还没有擦完的时候，就执行了HAL_FLASH_Lock()语句，锁住了flash操作，从而导致bsy一直没有复位。

查询flash操作时间：

可以看到128k的扇区进行擦除的时候，根据擦除方式的不同需要的时间也不同。

在程序中增加一段延时

这里增加5s的时间。

结果：失败！

依然不能进入debug。

改成获取BSY状态

结果：失败！

依然不能进入debug状态。

然后忽然想到之前用的是另一条语句，里面有检测BSY状态的，为什么依然不行呢？程序如下：

这里面用到的擦除语句是HAL库推荐适用的，其中的标志位检测、超时检测都有，但是也不能够进入debug。

。。。。。。

事情似乎陷入了僵局。。。。

解决问题：

事情到了这个阶段，我就要考虑一些其他问题了。

因为我用的软件版本是KEIL MDK 15.6 盗版的，然后下载器也是用的盗版的。通常盗版的会出现一些莫名奇妙的事情。

 

首先我用的下载器长下面这样：

当然，也有长这样的，做成跟官方外观一样：

但是其实本质上没啥区别。

更换软件环境比较麻烦，先换个烧录器吧。手里面有两种ST-LINK V2(盗版的)，U-link 2 （正版的），J-Link V8(盗版的)。

先换个J-link试一试：

斯巴达！！

斯巴达！！！

竟然进去了……

运行了一下，也没啥问题……

好吧，烧录器的锅~~~~~