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.

Hang at AbortHandler/UndefInstHandler

Other Parts Discussed in Thread: OMAPL138, TPS65070

Hi,
 
When I am debugging my program on ARM side of OMAP L138 with touch screen enabled, sometimes after a touch or even no touch for some period, the program goes to “AbortHandler/UndefInstHandler” and from then on hang at the infinite loop there.
 

 
The “AbortHandler/UndefInstHandler” defined in exceptionhandler.asm  and is part of OMAP L138 Starterware and can be found in folder <OMAPL138_StarterWare_1_10_03_03\system_config\armv5\omapl138\cgt>. Below is the code for it:
 
; The Abort handler goes to the C handler of abort mode. Note that the undefined
; instruction is not handled separately.
; if nothing is done in the abort mode, the execution enters infinite loop.
;
;
AbortHandler:
UndefInstHandler:
;
; Disable all the interrupts
;
        MRS     r0, cpsr                  ; Read from CPSR
        ORR     r0, r0, #0xC0             ; Clear the IRQ and FIQ bits   
        MSR     cpsr_c, r0                  ; Write to CPSR
        ADD     r14, pc, #0               ; Store the return address
        LDR     pc, _CPUAbortHandler      ; Go to C handler
;
; Go to infinite loop if returned from C handler
;
loop0:
        B       loop0 
 
The comment says that these statements are executed when ARM CPU enters Abort or executed undefined instruction. However, the function in the debug view only show the address of the final infinite loop0  statement of this mode without the functions that were still on the stack before the AbortHandler was entered. This single loop0  address makes it very difficult to find which problem has triggered the exception.
Also from CPSR we see that the ARM core mode in this situation is “11011” which according to “2.3 Processor Status Registers” of SPRUH77 means ARM core is in “Undefined mode”:
[quote user=""Undefined mode definition]
Undefined mode (UND): Executing an undefined instruction causes the ARM to enter undefined mode.
} 
 
All my code are written in C and then compiled eventually to binary codes, and I don’t think any legal C program can generate undefined assembly/binary instruction. What is really happening here?
 
Could someone tell me under which situations would the problem of ”Abort or executed undefined instruction” happen? How can we avoid this exception? And as the comments of it suggested:
; if nothing is done in the abort mode, the execution enters infinite loop.
So if it is something that cannot be prevented, what and how should we modify
AbortHandler:
UndefInstHandler:
to resume the program instead of hanging here forever?
 
 
Paul
  • I bump this thread because we need to demonstrate the project to our supervisors in a few days, and this problem is prevent the user interface from showing the normal behavior. Please give us some help on this.

    Paul

  • Paul,

    Even if your code is compiled properly, it can happen because of variety of reasons. If the code section is corrupted by chance then it can happen or if by mistake if your code jumps out of text/code segment it can happen. There are lot of reasons for this. But by tracing it down properly one can solve this problem. If you are using thumb mode for your code, can you just try disabling thumb mode completely and try compiling it for ARM mode only?

  • Renjith,

    Thanks for your reply.

    Could the corruption be due to voltage supply change of the L138 chip? This code has been running fine for several months, and we only start to see this problem until after a recent accident in which reversely connected batteries caused serious damages of a number of ICs and components on the board. For those whose problems explicitly manifested we had them replaced, but for resistors, caps, inductors, diodes and other smaller components we didn't have all of them replaced, and we have no idea if they had already been impaired or effectively "downgraded".

    My attempts of narrowing down the cause of this "undefined mode" show that the problem only happens when we are querying PMIC TPS65070 via I2C for touchscreen information (TPS65070 has integrated touchscreen driver):

    1. Before the battery accident the code runs for a whole night without any problem.
    2. After the accident and fix, if we disable all touchscreen I2C queries, the code still runs for a whole night without any problem.
    3. One we add the touchscreen I2C queries, in from secnds to minutes we will see the screen update stops and CCS debug view show that PC points to the infinite loop at end of the AbortHandler/UndefInstHandler.

    If any corruption can hapeen that could cause any "undefined instruction" to exist in the memory space according to SPRUH77's definition:

    Undefined mode (UND): Executing an undefined instruction causes the ARM to enter undefined mode.

    Then I reason that:

    1. The binary code produced by the compiler cannot be corrupted.

    2. If they corrupt, the corruption happens after they have been loaded into the memory.

    3. Since the symptom happens only when using TPS65070 I2C accesses, then we figure that it might be responsible for the symptom. However, TPS65070 is not a memory device and contains no code or data, so the only way it can resulted in any "corrupted instruction" in the memory is by:

    a. adversely affected DDR2 memory due to some abnormalities in output voltage which either

    A. caused text/data corruption in DDR2

    B. caused errors in text/data reading/reading, although actual data saved in the memory might not have been corrupted

    b. adversely affected L138 chip,

    A. caused text/data corruption in internal memory

    B. voltage abnormalities directly triggers "undefined mode". In fact, I found that the "undefined exception" cannot be suppressed by disabling the GER bit in AINTC.

    Then the chain which leads to this AbortHandler/UndefInstHandler error is most likely due to:

    TPS65070 I2C queries caused voltage abnormalities => due to reasons listed under (3) above we ran into "undefined mode".

    Do you think the reasoning makes sense? We are actually considering making a new board with entirely new components to see if our "good old days" free such problem could come back again.

     

    Paul

  • Also I am trying to find out the

    1. the instruction immediately precedes the jumping into the UndefInstHandler. However if the exception is caused by hardware problem then I don't know if this method could still give me relevant information.
    2. or the status of the chip immediately before jumping into the UndefInstHandler.

    Below is a screenshot of the CCS register view which is NOT captured when in UndefInstHandler. I post it here because I want to know what is the register definition for

    • R13/14/8/9/10/11/12_SVC/ABT/UND/IRQ/FIQ

    and what information I can draw from them? R13 without _xxx prefix is used by the compiler as stack pointer and R14 as PC, and these registers all show different values, so how should I interpret them?

    And if I run into UndefInstHandler, can I know from these registers the history/PC location of the code prior to this the exception?

     

    Paul

  • Paul,

    Using this dump we can infer where exactly it is crashing. Could you please share the .map file for the final binary that is running?

  • Renjith,

    Do you mean the register value dump like above after the crash (though the screenshot above is taken at normal running time and only for asking questions about register definitions)? Which registers should I look at to find out the routine that immediately preceded the crash?

    I am afraid I cannot put the .map file here since it is contains hundreds of function and variable names of the project.

     

    Paul

  • Paul,

    You've to mainly focus on Link register (R14) for your previous mode to figure get close to the function that was executed before crashing. Trying to correlate PC(r15) will also help in figuring out the exact instruction that failed. Also you if you simply keep gazing at the registers and the map file and the corresponding code, you'll be able to infer so much.

  • Renjith,

    Thanks for this information. I am trying to finding out the cause with this approach right now.

    Paul

  • Hi Paul, did you find the answer for yoru probelm? Could you please share with us

  • Hi Terrance,

    Could you please create new thread for your issue?

  • hi statin, thanks for the message. I already created thread in both starterware and AM335x but no resposne from members.

  • Hi Terrance,

    Sorry for the inconvenience.

    If you are board is OMAPL13x or single core DSP (C6xxx), Surely we will assist you on this forum.

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42.aspx?Sort=Active&pi74949=1

  • Hi Stalin, thanks for thr offer. I used OMAP few years back but now i am using sitara(AM335x), i am pretty much fixed most of the issue.

    once again thankyou very much

  • @terry

    Do you mind sharing details about how your resolved the issue? I'm having similar issues with the AM335x and can't figure out how to solve them.

    Thanks