TBE2 interrupt (UART2) causing address error exception

[newguy]

Processor: dsPIC33FJ256GP710A
Compiler: v4.141

Finally managed to track down what is happening but I have no idea why. Simply trying to use the TBE2 interrupt to send a message out via UART2 immediately causes an address error exception. Code is way too big to post here.

I'm leaning toward the interrupt vector for TBE2 being wrong. Any ideas?

[newguy]

Tiny update: interrupt vector is fine. TBE2 isr fires exactly once, then the address exception is thrown either upon exit from the isr, or shortly thereafter.

[Ttelmah]

Try increasing the stack size.

Best Wishes

[newguy]

Stack was ridiculously oversized already. Doubling it has no effect. Edit: as does quadrupling it.

[Ttelmah]

OK. Worth checking. You say 'ridiculously oversized'. You do realise that the stack on PIC33's, has to hold a lot of variables used locally by functions, not just the return addresses?. So a program with say function stack usage of just ten levels, may well need 500+ bytes of stack space. The default from CCS is often too small, especially if a lot of arithmetic is used. It's also possible to make any stack size overflow if (for instance), there is accidental recursion.
Your best bet, is to trap the exception interrupt and find what address the exception is coming from.

Best Wishes

[newguy]

Thanks for the tips, will try and deduce the address right away. Right now my stack size is 4096 (I know, too lazy to go back and find something more reasonably sized), but I tried 8192 and 16384 with no change in behaviour.

[Ttelmah]

OK. Yes I'll accept your stack _is_ 'ridiculously large'....

The default, is undersized when code starts to get more complex, and often throws this problem.

You don't need to 'deduce' the address, but just read it. It is on the stack, if you add code to trap the error.

Best Wishes

[newguy]

After the return from the first TBE2 isr, the program counter is pointing to 0x7FFFC, which isn't valid for the processor. Someone at CCS is digging through the list file to try & find a reason why.

...Will report when I know more.

[Ttelmah]

Have you looked at section 11 of the errata sheet?.
Does your TX interrupt do this?.

It is not stated what the effect of the premature interrupt will be if you load data at this point (I'd have guessed data corruption, rather than major crashing), but it does mean you possibly need to rethink using the TBE interrupt, Possibly use a timer interrupt at the character time, and send in this, rather than using TBE.

Best Wishes

[newguy]

Not applicable as I'm not using that mode, but out of desperation I did try the workaround. No change in behaviour.

The TBE2 code is identical to code associated with TBE/UART1. UART1's TBE code works flawlessly, UART2's causes an address exception.

CCS is on it. Seems as though I piqued their curiosity yesterday. Sent them the register dump they requested a few hours ago, with no reply yet.

[newguy]

Problem gets stranger....

So that I could work on other aspects of the project, I commented out the code that was causing the problem (a periodic transmit of a message on UART2, which in turn employed the TBE2 interrupt to actually send the message). As it was, the project did work prior to the tweaks. All I did was clean some things up.

Now that the rest of it is cleaned, I decided to try uncommenting the offending code. ....And the TBE2 isr() no longer generates an address exception.

I'm grateful that the problem has gone away, but I really hate that I don't know why!

Edit: the TBE2 isr() code didn't change either.

[FvM]

1. I'm convinced that address errors can be traced down to the primary cause, at least if they occur repeatedly.

As Ttelmah mentioned, it might be a silicon bug.

2. I think, the guesses about a stack overflow are essentially wrong. A stack overflow would trigger a trap on it's own.

[gpsmikey]

The problem with things that mysteriously "fix themselves" is that sooner or later, they tend to "un-fix themselves" (usually at a very inconvenient time). Be sure and let us know if you do find out what the actual cause is on this one

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3