• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 244 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 illegal instruction execution problem

Ben Qin
Intellectual 2690 points
Part Number: TMS320F28335

Hi Team,

There's an issue from the customer need your help:

My program is divided into two parts, one is the bootloader, which is allocated in sector A, and the other is the APP part, which is allocated in sector H. My problem is that when I jump into the APP from the bootloader after erasing the APP, the code executed at this time should be 0xff, which should trigger an interrupt of an illegal instruction, but this interrupt function is also allocated in the erased sector. Area, I want to know how the program will be executed at this time, whether it will fall into an infinite loop or continue to execute this illegal instruction. And during this process, I discovered that the xa12 (gpio84) pin actually outputs a low-level signal. This pin is clearly used to indicate whether to jump into sci_boot. It is an input pin. My entire program does not involve this. The pin performs configuration and other operations, and there is no external signal to drive it. How does it become an output and output a low level?

my subsequent investigation found that this problem occurred when the power failed when I was halfway through upgrading the APP, and it only occurred when the power supply slowly dropped. Later, I initially located the runtime's boot28.asm and executed the 25th line of the attached code. When gpio84 outputs a low level, because I can't understand assembly, I still don't understand how it operates the gpio port. I see this This piece of code should be a code to initialize variables. I guess it is because the initialization table is damaged and it writes random data to the GPIO register. But even if he writes 0 to the GPIO register, doesn’t the register still have mode and direction settings? No Is there still register write protection? How did it finally become a low level output?

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
****************************************************************************
* 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:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Best Regards,

Ben

  • 0
    TI__Guru* 95315 points
    Ben Qin said:
    when I jump into the APP from the bootloader after erasing the APP, the code executed at this time should be 0xff, which should trigger an interrupt of an illegal instruction,

    Correct.

    Ben Qin said:
    but this interrupt function is also allocated in the erased sector.

    By default, ITRAP ISR is in boot-ROM. If the CPU attempts to execute any unimplemented opcode, that would trigger an ITRAP and the device would branch to the ITRAP ISR in ROM, which is just an infinite loop. If the WD has not been disabled, the WDCNTR would overflow and reset the device. you can see this behavior on a part with blank Flash. If you power up such a part, you will see the -XRS pin pulsing repeatedly. 

    Ben Qin said:
    I discovered that the xa12 (gpio84) pin actually outputs a low-level signal.

    During the boot-mode selection phase, all 4 pins are input pins. They are only read, not driven.

    Ben Qin said:
    my subsequent investigation found that this problem occurred when the power failed when I was halfway through upgrading the APP, and it only occurred when the power supply slowly dropped.

    This is extremely risky, since it could potentially corrupt the password locations and permanently lock the device (with unknown passwords).  Once the supply voltage drops below VMIN, the device operation becomes unpredictable, which may explain why GPIO84 may be seen low.