This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28335: 28335非法指令执行问题

Part Number: TMS320F28335


我的程序分成两部分,一个是bootloader,分配在A扇区,一个是APP部分,分配在H扇区。我的问题是当我将APP擦除后从bootloader跳入APP时,这时候执行的应该是0xff的代码,这应该会触发一个非法指令的中断,但这个中断函数也是分配在被擦除的扇区,我想知道这个时候程序会怎么执行,是陷入死循环还是继续往下执行这个非法指令。而且在此过程中我发现xa12(gpio84)引脚居然会输出一个低电平信号,这个引脚明明是用来指示是否跳入sci_boot的,是个输入引脚,我的整个程序都没有涉及对这个引脚进行配置及其他操作,也没有外部信号驱动他,他是如何变为输出且输出一个低电平的?

  • 你好。我查看下相关资料后回复您。

  • 你好,我后续排查发现是在我升级APP到一半的时候电源掉电会出现这个问题,而且还要是电源慢慢跌落才会出现。后面我初步定位到runtime的boot28.asm中执行到所附代码的第25行时gpio84输出了低电平,因为看不懂汇编,现在没搞明白他是怎么操作到gpio口的,我看这一段应该是初始化变量的代码吧,我猜测是不是因为初始化表格被破坏了导致往GPIO的寄存器乱写数据,但就算他往GPIO的寄存器写0了,寄存器不是还有模式和方向设置吗,不是还有寄存器写保护吗,最后是怎么变成输出低电平的?

    ****************************************************************************
    *  PROCESS CINIT INITIALIZATION TABLE.  TABLE IS IN PROGRAM MEMORY IN THE  *
    *  FOLLOWING FORMAT:                                                       *
    *                                                                          *
    *       .word  <length of init data in words>                              *
    *       .word  or .long <address of variable to initialize>                *
    *       .word  <init data>                                                 *
    *       .word  ...                                                         *
    *                                                                          *
    *  If the variable's address is greater than 65535 (located in 'far'       *
    *  memory), then the address field of the cinit record will be 32-bits     *
    *  instead of the default 16-bits. The length value is negated to tag      *
    *  cinit records for those variables located in far memory.                *
    *                                                                          *
    *  The init table is terminated with a zero length                         *
    *                                                                          *
    ****************************************************************************
    	MOVL	XAR7,#cinit		; point XAR7 at start of table	
    	CLRC    TC		        ; reset TC bit used as far flag 
    	B 	START, UNC		; jump to start processing
    LOOP:
    	MOVB    AH,#0		        ; zero out upper addr bits
    	PREAD   AL,*XAR7		; load address of variable to be inited
    	ADDB    XAR7,#1			; point to initialization data
           	B	GET_DATA,NTC	        ; get data if variable is not far 
    	CLRC    TC		        ; reset TC bit used as far flag 
    	PREAD   AH,*XAR7	        ; otherwise, get hi bits of 22-bit addr
    	ADDB    XAR7,#1
    GET_DATA:	
    	MOVL	XAR6,ACC	        ; address
    	RPT	AR1			; repeat length + 1 times
    ||	PREAD   *XAR6++,*XAR7		; copy data from table to memory
    	
    	MOVL	ACC,XAR7		; using ACC as temp, point XAR7 to 
    	ADD  	ACC,AR1			; next cinit record since PREAD 
    	ADDB	ACC,#1			; doesn't change value of XAR7. 
    	MOVL	XAR7,ACC	
    START:
    	PREAD	AL,*XAR7		; load length
    	B	GET_ADDR,GEQ	        ; a length < 0 denotes far data	 
            NEG     AL		        ; negate value to get real length	
    	SETC    TC		        ; flag that the address field is 32-bits
    GET_ADDR:	
    	MOVZ	AR1,AL		        ; copy length value to loop register
            ADDB    XAR7,#1			; point to address field
    	BANZ	LOOP,AR1--		; if (length-- != 0) continue 

  • 我咨询下资深工程师后回复您。

  • 我猜测是为了初始化错误地址的变量,访问到了外部存储器了,所以这时候就不是GPIO功能,而是变成外部存储接口XINTF功能了,所以变成输出,我在XA15,XA14等其他pin上也发现有输出电平变化,而且GPIO的MUX寄存器也不是上电默认的值了。

  • 我的问题是当我将APP擦除后从bootloader跳入APP时,这时候执行的应该是0xff的代码,这应该会触发一个非法指令的中断

    对的

    但这个中断函数也是分配在被擦除的扇区

    默认情况下 ITRAP ISR是在bootROM中,如果 CPU 尝试执行任何未实现的操作码,这将触发 ITRAP,并且设备将分支到 ROM 中的 ITRAP ISR,这是一个无限循环。如果 WD 尚未禁用,WDCNTR 将溢出并重置设备。您可以在带有空白 Flash 的器件上看到此行为。如果给这样的器件上电,你会看到 -XRS 引脚反复脉冲。

    而且在此过程中我发现xa12(gpio84)引脚居然会输出一个低电平信号

    在引导模式选择阶段,所有 4 个引脚均为输入引脚。它们只是被阅读,而不是被驱动。

    我后续排查发现是在我升级APP到一半的时候电源掉电会出现这个问题,而且还要是电源慢慢跌落才会出现。

    这是非常危险的,因为它可能会损坏密码位置并永久锁定设备(使用未知密码)。一旦电源电压降至VMIN以下,器件运行就变得不可预测,这也许可以解释为什么GPIO84可能被视为低电平。

  • 这是非常危险的,因为它可能会损坏密码位置并永久锁定设备(使用未知密码)。一旦电源电压降至VMIN以下,器件运行就变得不可预测,这也许可以解释为什么GPIO84可能被视为低电平

    这个倒不会,bootloader是放在A扇区,升级时是不会擦除自身所在扇区的。而且GPIO变低不是指在掉电过程中信号异常,而是升级到一半电源慢慢跌落,升级未完成,然后重新上电后运行到不完整的程序时输出低电平。

  • 算了,现在我也不打算深究了,我准备在bootloader里检测升级程序的完整性,不完整就不跳进去执行了,继续待在bootloader等待。谢谢你的耐心答复!