莫名的的复位—Bootable image结构的‘秘密’

小恩GG

莫名的的复位—Bootable image结构的‘秘密’

前提

前段时间，小编使用tensorflow lite库在MIMXRT1050 EVK开发板上部署CNN模型过程中，无意中发现如果工程在使用比较多大的SDRAM空间时，使用MCUBootUtility或MCUXpresso Secure Provisioning工具生成bootable image在MIMXRT1050 EVK开发板上运行过程中，调用CNN模型时会触发莫名的复位现象，通过打印SRC_SRSR寄存器发现是lockup_sysresetreq复位源引发的，但是通过调试工具如Jlink或OpenSDA直接烧录的话，工程代码却能正常运行，最后通过反复比较与测试发现复位现象与bootable image结构有关（不了解bootable image结构的小伙伴，可以通过此博文—《恩智浦i.MX RT1xxx系列MCU启动那些事（6）- Bootable image格式与加载(elftosb/.bd)了解，那我们开始吧。

细节介绍

因为tensorflow lite库运行ML模型需要较大的RAM空间，而i.MX RT1050本身的FlexRAM只有512 byte，远远无法满足需求，所以需要SDRAM来提供充足的RAM空间，这就需要bootable image中添加DCD部分。
下面列出三组bootable image的IVT，Bootable image和DCD部分，分别对应：a) SD 卡的non-XIP启动，b) FlexSPI Nor flash的XIP启动，c) FlexSPI Nor flash的XIP启动，其中a，b项的bootable image是MCUXpresso Secure Provisioning工具生成的，而c项则是通过Jlink直接烧录的。

a) SD 卡的non-XIP启动

图 1

b) FlexSPI Nor flash的XIP启动 (MCUXpresso Secure Provisioning工具生成的)

图 2

c）FlexSPI Nor flash的XIP启动(Jlink直接烧录)

图 3

根据《恩智浦i.MX RT1xxx系列MCU启动那些事（6）- Bootable image格式与加载(elftosb/.bd)，上面三组bootable image的IVT，Bootable image和DCD部分都是符合结构规范要求的，那到底是什么原因导致a，b项的bootable image不能正常工作呢？
问题解决

经过多次比较与测试发现，问题与IVT的版本和application code的绝对地址设置有关（IVT的结构如下所示），其中结构体中的par代表版本号，通常为0x40或0x41，entry存储的是application code第一条执行指令的绝对地址，也有两种设置方式，一种是application code存储的首地址，另一种为application code的ResetISR中断函数指针指向的地址。

1. /** @ref hab_header structure */
   
2. typedef struct hab_hdr {
   
3.     uint8_t tag;              /**< Tag field */
   
4.     uint8_t len[2];           /**< Length field in bytes (big-endian) */
   
5.     uint8_t par;              /**< Parameters field */
   
6. } hab_hdr_t;
   
7. 
   
8. /** @ref ivt structure */
   
9. struct hab_ivt_v0 {
   
10.     /** @ref hdr with tag #HAB_TAG_IVT0, length and HAB version fields */
    
11.     hab_hdr_t hdr;
    
12.     /** Absolute address of the first instruction to execute from the image */
    
13.     uint32_t entry;
    
14.     /** Reserved in this version of HAB: should be NULL. */
    
15.     uint32_t reserved1;
    
16.     /** Absolute address of the image DCD: may be NULL. */
    
17.     uint32_t dcd;
    
18.     /** Absolute address of the Boot Data: may be NULL, but not interpreted any further by HAB */
    
19.     uint32_t boot_data;
    
20.     /** Absolute address of the IVT.*/
    
21.     uint32_t self;
    
22.     /** Absolute address of the image CSF.*/
    
23.     uint32_t csf;
    
24.     /** Reserved in this version of HAB: should be zero. */
    
25.     uint32_t reserved2;
    
26. };

复制代码

本着大胆猜测，小心求证的心态，发现将a,b项bootable image 中的par和entry按照c项格式修改后（如下所示），代码居然能成功地运行了。

a) SD 卡的non-XIP启动

图 4

b) FlexSPI Nor flash的XIP启动 (MCUXpresso Secure Provisioning工具生成的)

图 5

原因探究

跟同事讨论后，发现问题的根本原因与ROM code根据entry值实现跳转的方式有关，跳转函数的具体代码如下所示

1. void jump_to_entry(uint32_t entry)
   
2. {
   
3.     typedef void (*application_callback_t)(void);
   
4.     static application_callback_t s_app_callback;
   
5. 
   
6.     pu_irom_mpu_disable();
   
7. 
   
8.     __DMB();
   
9.     __DSB();
   
10.     __ISB();
    
11. 
    
12.     // The entry point is the absolute address of the call back function
    
13.     if ((uint32_t)entry & 1)
    
14.     {
    
15.         s_app_callback = (application_callback_t)entry;
    
16.     }
    
17.     // The entry point is the base address of vector table
    
18.     else
    
19.     {
    
20.         static uint32_t s_stack_pointer;
    
21.         // Ensure Core read vector table for destination instead of register
    
22.         volatile uint32_t *vector_table = (volatile uint32_t *)entry;
    
23. 
    
24.         s_stack_pointer = vector_table[0];
    
25.         s_app_callback = (application_callback_t)vector_table[1];
    
26. 
    
27.         // Update Stack pointer
    
28.         __set_MSP(s_stack_pointer);
    
29.         __set_PSP(s_stack_pointer);
    
30.     }
    
31. 
    
32.     __DSB();
    
33.     __ISB();
    
34. 
    
35.     // Jump to user application in the end
    
36.     s_app_callback();
    
37. 
    
38.     // Should never reach here
    
39.     __NOP();
    
40.     __NOP();
    
41. }

复制代码

当entry值是复位向量（Reset_Handler）函数地址（即奇地址）时，ROM code是直接通过函数调用的方式跳转到复位函数执行，而如果entry值是中断向量表首地址（即偶地址），ROM code会先将当前SP重设到application code指定的栈顶，然后再跳转到复位函数。
但是，MCUXpresso IDE的ResetISR函数没有重设SP的动作，所以当IVT中的entry是复位向量时，ROM code跳转到application code后依旧延用ROM code中的栈，而如果栈空间不足时，application code就会发生程序跑飞或Hard fault等错误。所以解决方法就需要手动在在MCUXpresso IDE的startup流程中加入重设SP操作，具体如下。

1. __attribute__ ((section(".after_vectors.reset")))
   
2. void ResetISR(void) {
   
3.     __asm volatile ("cpsid i");
   
4. 
   
5.     /* 新增SP重设代码 */
   
6.     __asm volatile ("MSR msp, %0" : : "r" (&_vStackTop) : );
   
7.     __asm volatile ("MSR psp, %0" : : "r" (&_vStackTop) : );
   
8. 
   
9.     SystemInit();
   
10. 
    
11.     // ...
    
12. }

复制代码

参考：IVT里的不同entry设置可能会造成i.MXRT1xxx系列启动App后发生异常跑飞

阅读全文

NXP管管

支持一下

andeyqi

感谢分享学习下