最近在做28377D在线升级（目前只用cpu1）,遇到一些问题希望得到各位专家朋友的帮助，谢谢！我采用的是底层烧写程序升级顶层应用程序的思路。我现在的做法是，dsp的boot方式设置为boot to flash模式，先将底层烧写程序用仿真器烧写到芯片（底层程序主要包括can接收程序和flashAPI函数，底层程序cmd里是将程序放在flashB区，底层程序用仿真器烧写后正常），上电后底层程序先通过can发送一帧数据给调试助手表明工作正常，然后等待can口接收顶层应用程序数据（接收完成后，会将程序数据写入flashE区，然后再将程序入口地址指向0x88000flashE处,我的理解是程序就直接执行新的应用程序）； 顶层程序为我需要被更新的程序，通过ccs6直接生成intel格式的8bit的hex文件, 然后将数据提取出来转换成can格式的txt文件， 通过can调试助手将这些数据（顶层程序） 发送给底层烧写程序， 烧写程序接收完收据后，将顶层程序写入到flashE区（写入的过程调用callexampleflashapi函数，先檫除再写入，用仿真器观看flashE区程序数据已写入），然后底层烧写程序将程序指针地址指向flashE的入口地址0x88000处，现在遇到以下问题：
1.执行到此处程序就进入到非法中断函数了；但是如果此处将程序指针指向原底层烧写程序入口地址0x80000处时，原底层烧写程序执行正常；但如果此处地址指向原底层烧写程序地址0x82000（即实际程序存放的地址位置即flashB）处，同样进入非法中断函数处；直观觉得跳到新程序入口地址0x88000和0x82000可能错误是同样原因？不知如何修改底层程序地址或顶层程序hex数据等格式才能使程序跳转到新程序入口地址正常执行？或者是我的这个思路本来就有问题，如何改正？
2.intel 8bit的hex 和16bit的有何区别，直观看就没有关系，上面之所以是生成8bit是因为查看flash程序区数据和8bit的存在一致关系,请问这是什么原因？