Cortex-M0核芯片bootloader调试过程

HT6025芯片（Cortex-M0核bootloader调试）

	最近STM32交期太长，仪表进行国产化芯片替代，使用HT6025（钜泉光电）进行boot调试时遇到下列问题

问题1：中断向量表映射问题

	使用BOOT程序跳转主程序，那么BOOT程序与主程序都有自己的中断向量表。在Cortex-M3的芯片中，芯片上电后先
	寻Reset_Handler向量位置，内部Flash（rom）中Reset_Handle的位置上存放的是程序的入口地址，找到入口地址后
	跳转执行，先执行System_init，设置时钟，设置中断向量偏移寄存器SCB->VTOR的值，如果BOOT跳转主程序后发
	生中断，则去VTOR偏移寄存器指向的位置寻址中断入口。Cortex-M0没有VTOR寄存器，则只能手动映射偏移。

解决方案：

	 Cortex-M0发生中断时固定从flash的0x08处寻找中断向量表入口，stm32的M0的核采用了硬件映射的办法，通过控制
	 BOOT1与BOOT0的引脚状态决定代码的启动位置，在BOOT里跳转前先将中断向量表拷贝到ram中，发生中断时去
	 RAM中寻中断向量表入口地址，这一块RAM不可给变量定义或申请用，只给中断向量表用。HT6025没有BOOT1与
	 BOOT0引脚，通过软件映射的办法，当App程序发生中断时，在flash的0x08处寻到boot程序的中断入口地址，然后
	 在boot程序内做一个跳转操作，在boot中断函数内跳转到主程序内运行：以TIM3中断为例：BOOT中断服务函数内做
	 以下操作：

void TIMER_3_IRQHandler()
{
	((void (*)(void))(*((uint32_t*)(FLASH_OFFSET+4*34))))(); 
}

	其他中断服务函数处理方法类似。

问题2：BOOT程序内使用中断，主程序的处理

 在BOOT程序内使用TIM2中断，主程序内未使用，则TIM2的中断服务函数写在BOOT，不需要进行跳转操作，发现boot使能TIM2中断后，主程序
 进入HardFault，关闭bootTIM2中断则主程序正常；

解决方案：

在boot跳转主程序之前关闭中断，在主程序内将TIM2中断失能，不再使用TIM2中断。当BOOT跳转主程序后，如果BOOT内的TIM2中断仍然发生，执
行BOOT的tim2中断函数后无法跳回主程序，导致hardfault。

	/* 关闭BOOT中的TIM2中断, 否则会引发系统异常 */
	HT_CMU_ClkCtrl1Config(CMU_CLKCTRL1_TMR2EN, DISABLE);
	HT_TMR2->TMRIE  &= ~0x0001;  
	NVIC_DisableIRQ(TIMER_2_IRQn);

问题3：BOOT接收到主程序的代码后写入FLASH，写入数据与程序文件数据不对应；

BOOT程序内通过规约接收主程序的数据，接收到侯将主程序的代码数据写入flash，发现写入flash后的数与接收到的数据流不一致，对比发现flash只
能从1变为0，而不能从0变为1，例如flash数据内原来是0x0C(二进制1100),可以变成0x08(二进制1000),而不能变成0x0f;

解决方案：

BOOT程序在写入flash之前执行一遍擦除操作；

/* 擦除100K数据 */
for (dw = 0; dw < 100; dw++)
	HT_Flash_PageErase(FLASH_ADDR + (0x400 * dw));

问题4：icf文件内指定0xFC0处为_password_start_，在BOOT和APP的icf文件处都指定了这个位置，而APP程序的起始地址为0x3000，已跨过该位置，引起异常；

引起的异常包括在IAR仿真环境下先仿真BOOT再仿真APP与先仿真APP再仿真BOOT，这两种仿真顺序写入flash内部数据不一致，而逻辑上应该是一
致的，并且BOOT写flash的时候会改写此处位置，导致无法正常在线仿真，通过BOOT写一遍flash就不能仿真了，dataSheet中关于此部分数据的描述如下：

解决方案：

仅在BOOT的icf文件内指定__ICFEDIT_password_start__ 位置，在主程序的icf文件中取消此处定义；

国产芯片还有很大的进步空间。