Other Parts Discussed in Thread: OMAPL138, TPS65070
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.
Other Parts Discussed in Thread: OMAPL138, TPS65070
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):
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
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
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 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