基于28377D的bootloader常见的问题

这件事情说来话长，在疫情期间，我做了一个基于TMS320F28377D的双核bootloader程序，通信协议选择的是
CAN通信。这此期间，我遇到了很多问题，都一一解决了，我遇到的问题，我也会给大家提出来，免得大家踩雷。

1、关于ecc和dataonly的问题：
烧写flash时，有两种选择：
（1）dataonly：这种方式需要关闭ecc，特点是：可以16位烧写，适合各种杂乱无章的程序。
关闭ecc的方法：
Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0x0;
（2）ecc烧写：这种方式需要开启ecc（寄存器默认开启），特点是：ecc校验，可以减少启动时代码出错的概率，但是必须64位烧写，或者128位烧写。即：CMD文件中必须有Align(4)或者Align(8)

我个人是建议选择ecc校验！

2、关于EALLOW问题
有一些f021-api函数库中的函数，在函数结束的时候，会EDIS，就会导致我们最前面的EALLOW失效！请大家一定注意！

3、最后一个是最大的坑！这个坑是我完全没有想到的！
写好双核bootloader程序后，烧写了一个双核的流水灯，可以正常工作，但是万万别想到，我写了一个epwm-adc的程序，程序比较大，每次都出错！，最奇怪的事情是，竟然部分功能是可以使用的。我百思不得其解，我通过以下的方式，做了一些小实验：1.用仿真器烧写，用bootloader启动，可以正常运行。2.用bootloader烧写，用bootloader启动，程序无法正常运行。我就寻思，是不是烧进入的程序有问题。我就用肉眼去看，前几行都是一样的，但是肉眼能看多少的东西呢。我用uniflash将两个程序的bin都导出,用BIN-TXT软件，将bin文件转换为txt，最后用beyond compare 4 对比两个txt文件的区别，还真被我找到了，有两行没有烧写进去，这两行共同的特点是检验和是0x00 ！

bug出现的原因是因为校验和，total%0x100 + checksum = 0x100
如果total%0x100 = 0的话，checksum应该是0x100,然而根据hex文件的格式，checksum只有两位，所以hex文件的
checksum为0x00。所以因为这个原因，遇到checksum为0x00的行，全部烧写不进去。
修改这个Bug后，程序可以正常运行！

码字不易，调试经验不易，转发请注明出处，以后给大家分享更多好玩有趣的小玩意。