TI中文支持网正在开发基于CAN的28377S在线升级，根据论坛的经验帖，大部分已经做出来了。思路如下，进入bootloader前的coderstart，首先判断需不需要升级，需要升级，进入升级状态，通信完成新的APP的接收，存入，升级成功后，进入APP运行。如果不需要升级，就直接跳转APP。
对于APP，成功运行后，升级状态标记为不用升级状态。如果接收升级指令后，能够改变升级标志。利用看门狗软件重启进入升级程序，进行判断，进而升级程序。
我已经完成了bootloader的接收程序和跳转，跳转到APP后还能发送升级指令成功返回到bootloader。但是如果程序运行在APP的时候按下复位按钮，程序会将进入异常中断，如果在APP运行的时候发送指令返回到bootloader再复位就不会有这个问题。
我进行了单步调试，发现运行在APP的时候按下复位按钮，FLASH_ECC会莫名奇妙的使能，然后触发NMI，这个和debug的时候restart的效果相同。但是一旦我使用debug的CPU reset，就不会有ECC的问题。我已经把APP和bootloader里面的ECC都关掉了，APP还屏蔽了Initflash()。不知道问题出在哪。请各位指教。
user4854571：解决了，判断升级不能放到code_start里面，感觉28377S复位自动开ECC ，必须放到InitSysCtrl()后面，而且再InitSysCtrl里面要关掉ECC。
正在开发基于CAN的28377S在线升级，根据论坛的经验帖，大部分已经做出来了。思路如下，进入bootloader前的coderstart，首先判断需不需要升级，需要升级，进入升级状态，通信完成新的APP的接收，存入，升级成功后，进入APP运行。如果不需要升级，就直接跳转APP。
对于APP，成功运行后，升级状态标记为不用升级状态。如果接收升级指令后，能够改变升级标志。利用看门狗软件重启进入升级程序，进行判断，进而升级程序。
我已经完成了bootloader的接收程序和跳转，跳转到APP后还能发送升级指令成功返回到bootloader。但是如果程序运行在APP的时候按下复位按钮，程序会将进入异常中断，如果在APP运行的时候发送指令返回到bootloader再复位就不会有这个问题。
我进行了单步调试，发现运行在APP的时候按下复位按钮，FLASH_ECC会莫名奇妙的使能，然后触发NMI，这个和debug的时候restart的效果相同。但是一旦我使用debug的CPU reset，就不会有ECC的问题。我已经把APP和bootloader里面的ECC都关掉了，APP还屏蔽了Initflash()。不知道问题出在哪。请各位指教。
user5314858：
回复 user4854571:
楼主还在吗。。。我也遇到这样的问题，但是没法解决。我用ccs烧进去的用户app，在BootLoader可以跳转过去，但是用BootLoader烧进去的用户app就无法跳转过去，但是在memory browser里面看分区数据，是和ccs烧进去的一样。
正在开发基于CAN的28377S在线升级，根据论坛的经验帖，大部分已经做出来了。思路如下，进入bootloader前的coderstart，首先判断需不需要升级，需要升级，进入升级状态，通信完成新的APP的接收，存入，升级成功后，进入APP运行。如果不需要升级，就直接跳转APP。
对于APP，成功运行后，升级状态标记为不用升级状态。如果接收升级指令后，能够改变升级标志。利用看门狗软件重启进入升级程序，进行判断，进而升级程序。
我已经完成了bootloader的接收程序和跳转，跳转到APP后还能发送升级指令成功返回到bootloader。但是如果程序运行在APP的时候按下复位按钮，程序会将进入异常中断，如果在APP运行的时候发送指令返回到bootloader再复位就不会有这个问题。
我进行了单步调试，发现运行在APP的时候按下复位按钮，FLASH_ECC会莫名奇妙的使能，然后触发NMI，这个和debug的时候restart的效果相同。但是一旦我使用debug的CPU reset，就不会有ECC的问题。我已经把APP和bootloader里面的ECC都关掉了，APP还屏蔽了Initflash()。不知道问题出在哪。请各位指教。
user4854571：
回复 user5314858:
那就是跳转的程序写错了吧，或者你是怎么判断是否有执行app呢？如果是用通讯判断的话。跳转之前需要清中断
正在开发基于CAN的28377S在线升级，根据论坛的经验帖，大部分已经做出来了。思路如下，进入bootloader前的coderstart，首先判断需不需要升级，需要升级，进入升级状态，通信完成新的APP的接收，存入，升级成功后，进入APP运行。如果不需要升级，就直接跳转APP。
对于APP，成功运行后，升级状态标记为不用升级状态。如果接收升级指令后，能够改变升级标志。利用看门狗软件重启进入升级程序，进行判断，进而升级程序。
我已经完成了bootloader的接收程序和跳转，跳转到APP后还能发送升级指令成功返回到bootloader。但是如果程序运行在APP的时候按下复位按钮，程序会将进入异常中断，如果在APP运行的时候发送指令返回到bootloader再复位就不会有这个问题。
我进行了单步调试，发现运行在APP的时候按下复位按钮，FLASH_ECC会莫名奇妙的使能，然后触发NMI，这个和debug的时候restart的效果相同。但是一旦我使用debug的CPU reset，就不会有ECC的问题。我已经把APP和bootloader里面的ECC都关掉了，APP还屏蔽了Initflash()。不知道问题出在哪。请各位指教。
user5314858：
回复 user4854571:
那也不对啊，因为用ccs烧写进去的app，我用BootLoader是能跳转过去的，直接跳转地址，asm(" LB 0x88000")；但是我用BootLoader把app烧写进去的话，BootLoader跳转不过去，然后就复位了。
正在开发基于CAN的28377S在线升级，根据论坛的经验帖，大部分已经做出来了。思路如下，进入bootloader前的coderstart，首先判断需不需要升级，需要升级，进入升级状态，通信完成新的APP的接收，存入，升级成功后，进入APP运行。如果不需要升级，就直接跳转APP。
对于APP，成功运行后，升级状态标记为不用升级状态。如果接收升级指令后，能够改变升级标志。利用看门狗软件重启进入升级程序，进行判断，进而升级程序。
我已经完成了bootloader的接收程序和跳转，跳转到APP后还能发送升级指令成功返回到bootloader。但是如果程序运行在APP的时候按下复位按钮，程序会将进入异常中断，如果在APP运行的时候发送指令返回到bootloader再复位就不会有这个问题。
我进行了单步调试，发现运行在APP的时候按下复位按钮，FLASH_ECC会莫名奇妙的使能，然后触发NMI，这个和debug的时候restart的效果相同。但是一旦我使用debug的CPU reset，就不会有ECC的问题。我已经把APP和bootloader里面的ECC都关掉了，APP还屏蔽了Initflash()。不知道问题出在哪。请各位指教。
user4854571：
回复 user5314858:
跳转语句你参考一下别的帖子有写，不是这么简单的一句。
正在开发基于CAN的28377S在线升级，根据论坛的经验帖，大部分已经做出来了。思路如下，进入bootloader前的coderstart，首先判断需不需要升级，需要升级，进入升级状态，通信完成新的APP的接收，存入，升级成功后，进入APP运行。如果不需要升级，就直接跳转APP。
对于APP，成功运行后，升级状态标记为不用升级状态。如果接收升级指令后，能够改变升级标志。利用看门狗软件重启进入升级程序，进行判断，进而升级程序。
我已经完成了bootloader的接收程序和跳转，跳转到APP后还能发送升级指令成功返回到bootloader。但是如果程序运行在APP的时候按下复位按钮，程序会将进入异常中断，如果在APP运行的时候发送指令返回到bootloader再复位就不会有这个问题。
我进行了单步调试，发现运行在APP的时候按下复位按钮，FLASH_ECC会莫名奇妙的使能，然后触发NMI，这个和debug的时候restart的效果相同。但是一旦我使用debug的CPU reset，就不会有ECC的问题。我已经把APP和bootloader里面的ECC都关掉了，APP还屏蔽了Initflash()。不知道问题出在哪。请各位指教。
user5314858：
回复 user4854571:
刚刚还用ccs测试了一下，对用BootLoader烧写进去的app，进行了debug的仅校验不烧写不清除，校验是成功的，可以直接运行起来。现在很懵逼，上面的测试证明了BootLoader的烧写没问题。其次，用ccs烧写的app，BootLoader又可以正常跳转运行。也就是说，跳转也没问题啊。我现在怀疑一点，就是会不会是ECC的问题，我想知道如何用汇编关闭ECC验证。
正在开发基于CAN的28377S在线升级，根据论坛的经验帖，大部分已经做出来了。思路如下，进入bootloader前的coderstart，首先判断需不需要升级，需要升级，进入升级状态，通信完成新的APP的接收，存入，升级成功后，进入APP运行。如果不需要升级，就直接跳转APP。
对于APP，成功运行后，升级状态标记为不用升级状态。如果接收升级指令后，能够改变升级标志。利用看门狗软件重启进入升级程序，进行判断，进而升级程序。
我已经完成了bootloader的接收程序和跳转，跳转到APP后还能发送升级指令成功返回到bootloader。但是如果程序运行在APP的时候按下复位按钮，程序会将进入异常中断，如果在APP运行的时候发送指令返回到bootloader再复位就不会有这个问题。
我进行了单步调试，发现运行在APP的时候按下复位按钮，FLASH_ECC会莫名奇妙的使能，然后触发NMI，这个和debug的时候restart的效果相同。但是一旦我使用debug的CPU reset，就不会有ECC的问题。我已经把APP和bootloader里面的ECC都关掉了，APP还屏蔽了Initflash()。不知道问题出在哪。请各位指教。
user4854571：
回复 user5314858:
那你的app里面sysctrl里面的flash初始化注释了吗
正在开发基于CAN的28377S在线升级，根据论坛的经验帖，大部分已经做出来了。思路如下，进入bootloader前的coderstart，首先判断需不需要升级，需要升级，进入升级状态，通信完成新的APP的接收，存入，升级成功后，进入APP运行。如果不需要升级，就直接跳转APP。
对于APP，成功运行后，升级状态标记为不用升级状态。如果接收升级指令后，能够改变升级标志。利用看门狗软件重启进入升级程序，进行判断，进而升级程序。
我已经完成了bootloader的接收程序和跳转，跳转到APP后还能发送升级指令成功返回到bootloader。但是如果程序运行在APP的时候按下复位按钮，程序会将进入异常中断，如果在APP运行的时候发送指令返回到bootloader再复位就不会有这个问题。
我进行了单步调试，发现运行在APP的时候按下复位按钮，FLASH_ECC会莫名奇妙的使能，然后触发NMI，这个和debug的时候restart的效果相同。但是一旦我使用debug的CPU reset，就不会有ECC的问题。我已经把APP和bootloader里面的ECC都关掉了，APP还屏蔽了Initflash()。不知道问题出在哪。请各位指教。
user5314858：
回复 user4854571:
我之前就是用论坛的其他的经验贴的跳转，后面为了debug可以看到跳哪里去了，才用汇编的，然而，换回来函数指针跳转，还是不行。
正在开发基于CAN的28377S在线升级，根据论坛的经验帖，大部分已经做出来了。思路如下，进入bootloader前的coderstart，首先判断需不需要升级，需要升级，进入升级状态，通信完成新的APP的接收，存入，升级成功后，进入APP运行。如果不需要升级，就直接跳转APP。
对于APP，成功运行后，升级状态标记为不用升级状态。如果接收升级指令后，能够改变升级标志。利用看门狗软件重启进入升级程序，进行判断，进而升级程序。
我已经完成了bootloader的接收程序和跳转，跳转到APP后还能发送升级指令成功返回到bootloader。但是如果程序运行在APP的时候按下复位按钮，程序会将进入异常中断，如果在APP运行的时候发送指令返回到bootloader再复位就不会有这个问题。
我进行了单步调试，发现运行在APP的时候按下复位按钮，FLASH_ECC会莫名奇妙的使能，然后触发NMI，这个和debug的时候restart的效果相同。但是一旦我使用debug的CPU reset，就不会有ECC的问题。我已经把APP和bootloader里面的ECC都关掉了，APP还屏蔽了Initflash()。不知道问题出在哪。请各位指教。
user5314858：
回复 user4854571:
注释了，里面是这样的，
void InitSysCtrl(void)
{
DisableDog();
#ifdef _FLASH
memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);//InitFlash_Bank0();
#endif
EALLOW;
GPIO_EnableUnbondedIOPullups();
CpuSysRegs.PCLKCR13.bit.ADC_A = 1;CpuSysRegs.PCLKCR13.bit.ADC_B = 1;CpuSysRegs.PCLKCR13.bit.ADC_C = 1;CpuSysRegs.PCLKCR13.bit.ADC_D = 1;
if(*((Uint16 *)0x5D1B6) == 0x0000){
AnalogSubsysRegs.ANAREFTRIMA.all = 31709;AnalogSubsysRegs.ANAREFTRIMB.all = 31709;AnalogSubsysRegs.ANAREFTRIMC.all = 31709;AnalogSubsysRegs.ANAREFTRIMD.all = 31709;}
CpuSysRegs.PCLKCR13.bit.ADC_A = 0;CpuSysRegs.PCLKCR13.bit.ADC_B = 0;CpuSysRegs.PCLKCR13.bit.ADC_C = 0;CpuSysRegs.PCLKCR13.bit.ADC_D = 0;EDIS;
#ifdef _LAUNCHXL_F28377SInitSysPll(XTAL_OSC,IMULT_40,FMULT_0,PLLCLK_BY_2);
#elseInitSysPll(XTAL_OSC,IMULT_20,FMULT_0,PLLCLK_BY_2);
#endif
InitPeripheralClocks();
}
我把InitFlash_Bank0()，给注释了，还有其他办法不？
正在开发基于CAN的28377S在线升级，根据论坛的经验帖，大部分已经做出来了。思路如下，进入bootloader前的coderstart，首先判断需不需要升级，需要升级，进入升级状态，通信完成新的APP的接收，存入，升级成功后，进入APP运行。如果不需要升级，就直接跳转APP。
对于APP，成功运行后，升级状态标记为不用升级状态。如果接收升级指令后，能够改变升级标志。利用看门狗软件重启进入升级程序，进行判断，进而升级程序。
我已经完成了bootloader的接收程序和跳转，跳转到APP后还能发送升级指令成功返回到bootloader。但是如果程序运行在APP的时候按下复位按钮，程序会将进入异常中断，如果在APP运行的时候发送指令返回到bootloader再复位就不会有这个问题。
我进行了单步调试，发现运行在APP的时候按下复位按钮，FLASH_ECC会莫名奇妙的使能，然后触发NMI，这个和debug的时候restart的效果相同。但是一旦我使用debug的CPU reset，就不会有ECC的问题。我已经把APP和bootloader里面的ECC都关掉了，APP还屏蔽了Initflash()。不知道问题出在哪。请各位指教。
user5314858：
回复 user4854571:
可以参考一下你的代码吗？或者把我的源码发给你看看？huangjoker0913@163.com
