TI中文支持网Part Number:TMS320F280025
当前程序结构：
bootloader：sector0~sector1,上电启动此程序，判断app_temp有程序则擦除app区域，复制app_temp数据至app区域后擦除app_temp区域，然后跳转至app
app:sector2~sector8,当前app程序，接收到升级指令时擦除app_temp区域，将接收的数据写入app_temp区后利用看门口重启DSP
app_temp: sector9~sector15，用于升级的临时app区
上位机与DSP通讯，发送程序bin数据，app中擦除指定app_temp后将接收的bin数据写入app_temp。
当上位机连续不中断的发送完成整个bin文件后，DSP能正常擦除、编程、跳转。
当上位机发送数据的过程中，关闭上位机，此时只写入了一部分数据到app_temp中。
后续如果尝试重新下载程序，则DSP会在擦除有数据的扇区时复位，Debug发现此时程序进入ESTOP0。
利用CCS强制下载app程序同时擦除app_temp区，则可以继续用上位机下载程序。
请问当app_temp中有数据的时候，app程序中想要擦除app_temp为什么会失败？
现在解决办法是修改bootloader代码，其上电后先进行正常升级判断，最后不管进行了升级都擦除app_temp区域。
这样当app在升级时中断，再次下载程序时会导致dsp重启进入bootloader擦除app_temp区域，此后再次下载程序就可以正常擦除。
BarbiQ -：
bootloader每次上电都擦除FLASH的扇区，是否会影响FLASH寿命？
,
Ben Qin：
FLash本来就有寿命的，大约是10万次。
,
BarbiQ -：
那我现在bootloader每次上电擦除Flash肯定不行了。
那前面提到的问题：App中接收上位机发来的bin文件，接收一个包校验成功后写入App_temp区，更新到一半的时候，上位机退出。
此后再也不能在App中擦除App_temp区，否则会进入ESTOP0。
这个问题如何解决呢？
说明一下，程序中使用的是Boot ROM中的Flash API，所有调用Flash API的函数都运行于RAM中，而Flash API函数本身运行于ROM中。
,
Ben Qin：
BarbiQ – said:bootloader：sector0~sector1,上电启动此程序，判断app_temp有程序则擦除app区域，复制app_temp数据至app区域后擦除app_temp区域
如果app_temp中的数据不完整，判断是有数据还是没有数据？
BarbiQ – said:后续如果尝试重新下载程序，则DSP会在擦除有数据的扇区时复位，Debug发现此时程序进入ESTOP0。
你是指擦除app区域的时候吗？
,
BarbiQ -：
不是。
是在app(sector2~sector8)程序中擦除app_temp区域(sector9~sector15)
,
Ben Qin：
Ben Qin said:如果app_temp中的数据不完整，判断是有数据还是没有数据？
在判断是有数据的情况下，此时程序依然将app_temp中的内容复制到app所在区域中，然后运行app，那么此时app是不完整的，运行会有问题。
,
BarbiQ -：
app中将接收的bin文件写入app_temp区域
bootloader会检查app_temp区域程序有效性（检查整个区域头部和尾部的特定标志字），如果程序有效，才会复制到app区域。
app是完整的，我直接用CCS下载程序到app区域(sector2~sector8)，不擦除其他扇区
app运行时也是同样的情况。
,
BarbiQ -：
另外还想问3个问题：
1.如果一个扇区之前已经擦除，且后续没有再编程过
此时对此扇区进行擦除，Flash_API是否会真的在进行一次物理擦除操作？
还是说如果扇区已经是Blank状态，就不会再真的进行物理擦除？
2.在擦除一个扇区之前，如果调用
Fapi_doBlankCheck()
函数判断一下该扇区是否为Blank状态，如果已经是Blank则不调用擦除函数
这样的逻辑是否可以减少次数？
比如app_temp包含sector9~sector15
但是实际上程序并没有那么大，可能sector9~sector12是有效数据，sector13~sector14由CMD文件指定填充0xFFFF,sector15除末尾有指定标志字外都是0xffff
3.如果一个扇区被cmd文件指定全部填充了0xFFFF
那么此时调用Fapi_doBlankCheck()，会返回什么状态？是已擦除还是未擦除？
,
BarbiQ -：
追加一些信息：
DSP上电后启动bootloader，bootloader检查app_temp区域，如果此区域有完整程序，则擦除app区，并将app_temp区内容拷贝到app区域，然后跳转到app区域运行app程序。
在bootloader中擦除app区域，擦除app_temp区域都没有任何问题。
app程序中擦除app_temp区域会存在问题，app程序中擦除bootloader区域也存在问题。
实测在app程序中擦除bootloader区域(sector0~sector1)，sector0确认被擦除，但是因为程序ESTOP0异常，sector1一直无法擦除。
请问app程序中擦除扇区失败，是否跟app程序是由bootloader跳转过来运行有关系？
,
Ben Qin：
您好，我需要咨询下资深工程师，一旦得到回复会立即回复您。
,
BarbiQ -：
实际测试后自己回答自己的问题：
1.如果一个扇区之前已经擦除，且后续没有再编程过
此时对此扇区进行擦除，Flash_API是否会真的在进行一次物理擦除操作？ 答：(不会)
还是说如果扇区已经是Blank状态，就不会再真的进行物理擦除？ 答：(是的）
2.在擦除一个扇区之前，如果调用
Fapi_doBlankCheck()
函数判断一下该扇区是否为Blank状态，如果已经是Blank则不调用擦除函数
这样的逻辑是否可以减少次数？
答：（不会，因为已经擦除或被0xFFFF完全填充的扇区不会被再次擦除）
比如app_temp包含sector9~sector15
但是实际上程序并没有那么大，可能sector9~sector12是有效数据，sector13~sector14由CMD文件指定填充0xFFFF,sector15除末尾有指定标志字外都是0xffff
3.如果一个扇区被cmd文件指定全部填充了0xFFFF
那么此时调用Fapi_doBlankCheck()，会返回什么状态？是已擦除还是未擦除？
答：（返回已擦除状态）
,
BarbiQ -：
对上述问题做一下汇总总结：
1.在bootloader中可以正常擦除app区和app_temp区；
2.在app区中不能擦除app_temp区，擦除操作会导致app程序复位，但是该复位与上电复位不一样，其不会导致dsp先运行bootloader。
3.之前之所以说如果app_temp区为空时，app程序能正常擦除app_temp区，那是因为Flash_API不会再次擦除空扇区，所以不会导致出错；
而一旦app_temp区有数据，app程序中会真的对app_temp进行物理擦除操作。
4.bootloader与app的差异在于，上电先启动bootloader，然后通过LB指令跳转到app运行
,
Ben Qin：
您现在的问题解决了吗？或者您还有其他的问题？
,
BarbiQ -：
你好。现在的问题在于：在app区运行的程序中不能擦除app_temp区。
1.在bootloader中可以正常擦除app区和app_temp区；
2.在app区中不能擦除app_temp区
4.bootloader与app的差异在于，上电先启动bootloader，然后通过LB指令跳转到app运行
,
Ben Qin：
好的，我咨询下资深工程师后回复您。
,
Ben Qin：
参考下工程师的回复：
I think this is going to be challenging to debug with just written description, it may be better to give some visual representation of the flash sectors, especially when the host PC stops sending data. Along those lines, has customer looked at what is in flash when this occurs? This should give some clue of how the updated handled things
Can you give the address where the code is stopped when they connect? This might just be artifact of emulator connected and EMUBOOT not defined.
