Getting exception says "Exception vector name: address error"

[TVNAIDU]

I am getting exception, any idea?.

EXception Vector Name: Address error

pointing to this routine "UART1_TXRX_ISR".

[TomE]

Yes.

But this isn't Twitter. You're not limited to 140 or so bytes here.

What CPU? What hardware? Include some of your code. Include disassembly.

You're more likely to get help if you show some you've done some work first. Like reading the manuals, and asking questions about the sections in the manuals if you don't understand them (or if they're missing, corrupted or plain wrong).

You should also refrain from asking questions already answered in this Forum. Search before posting.

Have you tried typing "coldfire address error" into Google?

[TVNAIDU]

Well I searched on this forum before posting, I can see somebody had an issue with stack and heap.

Here I am using MCF52233 chipset, I am getting this exception after I increased html_vars array size and html_vars_flags size from 32 to 98. I am getting this exception, also I added code to initialise those Two arrays in one of my task, if I run for 20 Hours I am getting this exception. I can see it stops at at beginning of routine UART1_TXRX_ISR. I need this html_vars atleast array size 100 since I need to display some values on web interface. this is how did initialize those

html_vars[0] = val1;

html_vars_flags[0] = 1;

........

.......

html_vars[97] = val1;

html_vars_flags[97] = 1;

Exception vector Name: address error
Ox00E60000
panic
dtrap
printf

atleast any document tells about what are the chnaces for this address error?

[TomE]

The Reference Manuals and the ColdFire Core documents tell you what causes an Address Error. From your Reference manual:

3.3.4.2 Address Error Exception
Any attempted execution transferring control to an odd instruction address (if bit 0 of the target address is
set) results in an address error exception.
Any attempted use of a word-sized index register (Xn.w) or a scale factor of eight on an indexed effective
addressing mode generates an address error, as does an attempted execution of a full-format indexed
addressing mode, which is defined by bit 8 of extension word 1 being set.
If an address error occurs on a JSR instruction, the Version 2 ColdFire processor calculates the target
address then the return address is pushed onto the stack. If an address error occurs on an RTS instruction,
the Version 2 ColdFire processor overwrites the faulting return PC with the address error stack frame.

You need to examine the stack and decode the address error stack frame to see why it did this.

The most likely cause is a buffer overrun on your stack corrupting a return address or a pointer. You may also be overrunning your allocated stack area. What is the Stack Pointer when it fails? Don't tell me this, I can't help you. You have to compare where the stack is and what is on the stack with the memory allocated for it. It might be an odd stack pointer or program counter.

"Ox00E60000" looks to be a memory boundary of something. Is that the PC? Examine the code that is printing the Exception and see what is is printing there.

> > Have you tried typing "coldfire address error" into Google?

Follow some of the OTHER listed causes and fixes for address errors. The one you read may not match the problem you have.

20 hours? Does it always fail after 20 hours? Does it depend on the HTML messages coming in that make it fail? Does it have a Memory Leak?

[TVNAIDU]

I am trying to find PC and SP registers window on Code warrior, I cannot see any window for that. but I just copied all info from debugger window.

Stack                                             Variables: Live Value

printf                                              ReadUSR1 No address info available for variable

                                                     UART1RxBuffer                0x20001988

printk                                             UART1RxPtr                   0x000187BE

printk_putc                                     UART1Status                  0

out_char                                         UART1TxCounter             32

uart_putc                                        UART1TxPtr                  0x000194A2

0x2000014C (0x2000014C)

DummyFn1

mcf5xx_exception_handler

UART1_TXRX_ISR

　

　

　

void UART1_TXRX_ISR()

{

-> uint8

　

}

　

　

sometimes it runs for 10 Hours and then crashes, sometimes 20 hours and it crashes. But I see this crash only after I increased html_vars array size from 32 to 98, also html_vars_flags arrays also 32 to 98, earlier I am running for somany weeks, I never see exception at all. is there any file shows stack overrun / any abonormal?.

　

[TomE]

You have to find the registers window and then you need to know how to dump the stack in memory and examine it.

You need someone to help you physically present, looking at the screen or you have to learn a huge amount. There's nothing in what you've provided that could begin to help with this.

it might be better to ask this question on the Code Warrior forum.

[TVNAIDU]

I just found this definiton from ref. manual. I see this exception after I increased from html_vars[32] to html_vars[98] and html_vars_flags[32] to html_vars_flags[98] and I initializes those array elements inside my task (html_vars[0] = 0x0; html_vars[flags[1] = 1; ......) Is it anything wrong with increase array size for this address error. according to below def, it says "odd instruction address", I cannot find any link for my change to exception?

Address Error Exception
Any attempted execution transferring control to an odd instruction address (that is, if bit 0 of the target
address is set) results in an address error exception.
Any attempted use of a word-sized index register (Xn.w) or a scale factor of 8 on an indexed effective
addressing mode generates an address error as does an attempted execution of a full-format indexed
addressing mode.

[TomE]

>> The most likely cause is a buffer overrun on your stack corrupting a return address or a pointer.

Have you done anything to investigate this?

You've never actually said WHAT code you're running, which doesn't halp me at all. I can't see your code from here.

Google finds http://www.freescale.com/files/microcontrollers/doc/app_note/AN3779.pdf

So I assume you've copied that and are making changes.

> r I increased html_vars array size and html_vars_flags size from 32 to 98

Is that all you have to do? Maybe some other part of the HTML code assumes 32 variables, and by increasing those two arrays only means you're forcing some other part of the code to walk off the end of something. Search for all other arrays in the code that are sized at 32, or at least between 32 and 98.

I've sent you a private message. Read that before you powst anything else here.

[TVNAIDU]

finally I found the reason for exception. I am getting exception when I run with debugger, if I run from flash I dodn't see exception, the reason for exception with debugger is, the version on flash is not same as what with debugger, after I did clean build and install latest into flash, then run with debugger, no crash for 48 Hours, let me fro few more days and see.

Thanks for your support.

[TomE]

> finally I found the reason for exception. I am getting exception when I run with debugger,

You are SEEING the exception when you run with the debugger. The debugger "hooks" all of the nasty exceptions (that indicate that something bad happened) and tells you about them.

> if I run from flash I dodn't see exception,

That doesn't mean it isn't happening. It is possible that your system is set up so that either a watchdog resets the system when an exception happens, or maybe the exception handlers reset the chip.  Or maybe they ignore the error and try to keep going (which is worse). How are they set up? Do you know? Can you read the code and find out what it does?

For some applications, having it crash and reset is a disaster. For other devices that don't have to "remember" the current state (like just displaying outputs from a different system) it might be acceptable.

Could you tell the difference between "running after 48 hours continuously" and "running after 48 hours and a few or a few dozen reboots"? The easiest way to tell the difference is to have a visible "uptime" counter somewhere. In your case you could add this to the web page the device displays. If it is still showing 48 hours of uptime after 48 hours then it is OK. Otherwise you've still got problems.