Flash Protection功能，即对某一段Flash空间进行写保护配置，防止某些敏感信息误被擦写，只允许读访问权限。这个功能在某些领域还是很有必要的，比如对Bootloader升级功能代码或者一些需要给每个芯片烧写序列号方便对产品跟踪管理等应用，都是需要对这些敏感信息进行写保护的，防止其被意外的擦写从而造成永久性数据丢失。

    飞思卡尔Kinetis系列提供了比较好用的Flash保护机制，通过4个Flash保护寄存器中的32个位对芯片Flash空间划分成32个区域进行写保护配置，也就是说不同Flash大小的芯片其最小可配置保护单元大小是不一样的（32个位里面每个位用来控制一片地址段范围的写保护），比如128k Flash大小其最小保护单元为4kB空间（128/32=4），64k Flash大小的芯片其最小保护单元为2kB（64/32=2），32k则为1kB（32/32=1），但是对小于32k的空间呢（再去分成32份就不均匀了，肿么办呢），以24k FLash芯片为例，飞思卡尔对这种情况的处理是其最小保护单元仍为1kB，而32位中的后8位就被忽略掉了，以此类推16k和8k Flash的情况。具体Flash保护的配置说明如下图所示：

    说到这可能会有人质疑，我是不是有点跑题了，标题不是说下载失败的解决办法嘛，呵呵，我只有嘿嘿一笑，不要着急，先介绍下背景嘛，嘿嘿。那先看下图红色标示所示，即如果Erase Flash Sector指令要擦除的地址范围被保护会造成擦写失败返回错误，这样的话问题就来了，我们知道在使用IDE开发环境IAR或者Keil调试下载程序的时候（一些第三方烧写工具也是一样）一般都是使用Erase Flash Sector指令只对代码用到的Flash空间进行擦除然后再Program，而没有用到的Flash其不会去花额外的时间去全擦除，但是这种情况就会带来一个潜在的问题，一般情况下我们不会去动被保护的Flash区（没事不会闲着去找麻烦，呵呵），但是如果我们打算把芯片重新编程来过或者想擦掉被保护区的信息了怎么办呢，如果使用IAR或者Keil的Program或者Erase功能它都是触发Erase Flash Sector指令去挨个扇区擦写的（我测试了下IAR下的Erase All指令貌似也是会失败的，因为其调用的是Erase All Block指令，这个指令也是受Protection限制的），这就会造成擦写失败，那肿么办呢。

    当然天无绝人之路，飞思卡尔自然不可能弄出这么一个bug（岂不是成了OTP了，哈哈），我们继续往下看，终于柳暗花明又一村啊，如下图所示，终于有一个指令可以治一治这尊“大神”了。那问题又来了，怎么使用这个指令呢，呵呵，晕，俺又开始卖官司了，哈哈。

    实际上使用这个指令比较简单的方式是使用Jlink Commander这个dos下的工具，我们将Jlink与板子连好并上电，然后打开Jlink Commander窗口，敲入“unlock kinetis”指令并按回车如下图（这个指令实际上就是通过JTAG或者SWD接口给芯片发送Mass Erase指令即上面所述的指令），等待返回擦写成功的指令即可，然后我们再按照正常流程通过IAR或者Keil就可以正常擦写和调试下载代码了，很神奇啊有木有，哈哈。

    好了，今天状态不错，写了这么多依然兴奋有余，手感甚佳啊，哈哈（发现在火车上写文章状态一直不错）。就聊到这了，休息休息，养精蓄锐，未完待续~