 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Tressie
Joined: 07 Apr 2012
Posts: 12
|
| UART RX ISR Causes Trap Reset? |
 Posted: Fri Jun 29, 2012 6:54 pm |
 |
|
Hi,
I'm using the CCS Modbus demonstration code on a dsPIC33FJ128, though without the CCS UART driver, and with my own UART set-up routine.
Periodically, the controller will undergo trap resets, though this doesn't happen whenever I comment-out all code within the UART RX ISR. I've marked every variable used within the ISR, and its subroutine calls, as volatile, though to no avail. How should I now proceed, in order to eliminate this pesky problem?
Other clues: The same RX ISR, running in Modbus slave mode on a PIC24, appears to become prone to the trap reset, only when 'read_eeprom()' is being called. Eliminate this from the task loop, and all functions as should do.
Any suggestions on what might be the cause for, or how to proceed in eliminating this fault, would be most welcome. Sorry, I'm not allowed to post code.
T.  |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19368
|
|
| Posted: Sat Jun 30, 2012 12:47 am |
|
|
Have you increased the stack size from the default?.
Best Wishes |
|
|
Tressie
Joined: 07 Apr 2012
Posts: 12
|
| Good Question? |
| Posted: Sat Jun 30, 2012 4:38 am |
|
|
| Ttelmah wrote: | Have you increased the stack size from the default?.
Best Wishes |
Hi Ttelmah,
Thanks for the valuable input.
Yes, I think that I've addressed the stack size possibility. I tried adding '#build (stack=256)' after the fuse configuration, though it seemed to make no appreciable difference in this particular case.
Thanks again.
T. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19368
|
|
| Posted: Sat Jun 30, 2012 7:24 am |
|
|
Er. I think you will find 256, is the default size. It is _not enough_, if you use any of the complex printf formats, more than perhaps one or two ISR's, some of the maths functions, etc. etc..
Take it up to 512, or 1024.
Best Wishes |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Jun 30, 2012 7:58 am |
|
|
First point is to identify the kind of error trap causing the reset.
I guess you get an unhandled trap reset, by implementing an address error and stack overflow trap handler you are able to distinguish between the two most likely exceptions and in case of an address error locate the line of code causing it.
Examples for trap handlers have been previously posted at ccs forum. |
|
|
Tressie
Joined: 07 Apr 2012
Posts: 12
|
|
| Posted: Sat Jun 30, 2012 8:15 am |
|
|
| Ttelmah wrote: | Er. I think you will find 256, is the default size. It is _not enough_, if you use any of the complex printf formats, more than perhaps one or two ISR's, some of the maths functions, etc. etc..
Take it up to 512, or 1024.
Best Wishes |
Hi Ttelmah,
Ah, okay. I might have tried 512-bytes for the stack size, but I have a number of ISR's running concurrently. I'll give enlarged stack sizes another go on Monday.
Thanks again.
T. |
|
|
Tressie
Joined: 07 Apr 2012
Posts: 12
|
|
| Posted: Sat Jun 30, 2012 8:21 am |
|
|
| FvM wrote: | First point is to identify the kind of error trap causing the reset.
I guess you get an unhandled trap reset, by implementing an address error and stack overflow trap handler you are able to distinguish between the two most likely exceptions and in case of an address error locate the line of code causing it.
Examples for trap handlers have been previously posted at ccs forum. |
Hi FvM,
Thanks for the valuable input.
Yes, I'm hoping that its maybe just the CCS compiler generating dodgy (CRC?) indexed array addresses. Some compilations work reliably, whilst virtually identical source can compile down to really unreliable code.
Hmm, won't be complaining if anyone can help me find trap handler example posts, that a relative newcomer might find understandable.
Thanks again for the advice, FvM.
Regards,
T.  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19368
|
|
| Posted: Sat Jun 30, 2012 12:16 pm |
|
|
Seriously, if you are generating indexed array addresses, from a calculation that may have problems, then _you_ should test the values against bounds before using them.
This would also allow you to rule this out.
Generate an array access macro, that accepts the array name, the index and the limits, and check the former against the latter before use.
Best Wishes |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Jun 30, 2012 5:08 pm |
|
|
An #INT_ADDRERR example http://www.ccsinfo.com/forum/viewtopic.php?t=36479
Hints for #INT_STACKERR http://www.ccsinfo.com/forum/viewtopic.php?t=40083
| Quote: | | Ah, okay. I might have tried 512-bytes for the stack size, but I have a number of ISR's running concurrently. I'll give enlarged stack sizes another go on Monday. |
No effect of increasing the stack size suggests that it's no simple stack overflow.
I'm not sure if you actually have nested interrupts because they would require reenabling interrupts inside the
ISR and assignment of different interrupt priorities. Do you? Otherwise no ISR would start before a "concurrent"
ISR has finished. |
|
|
Tressie
Joined: 07 Apr 2012
Posts: 12
|
|
| Posted: Sun Jul 01, 2012 12:43 am |
|
|
Hi FvM,
Ah, okay. I brushed past your #INT_ADDRERR example previously, but didn't quite grasp how it works. Seems I have a better handle on it this time. During the trap interrupt, the handler simply saves the address of the instruction that caused the error. I then maybe work back through the assembly to the C source code line that produces the fault, and maybe find some workaround. Yep, that'll work!
Yes, you're quite right. My ISR's are not at all 'concurrent'. It seems that each will run exclusively, as I'm not re-enabling other ISR's to run within each. Sorry, my bad.
Thanks for the #INT_ADDRERR handler example especially, FvM. Pleasingly, I'm all tooled-up to tackle this one again come Monday morning.
Regards,
T.  |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sun Jul 01, 2012 12:51 am |
|
|
| As said, an address error trap is the most popular reset cause, brought up either by application code or compiler bugs. An important aspect of the address error trap is that it simply skips the faulty instruction, and if the trap is handled, continuous normal program operation. So it's an easy way to find out, if the problem is actually caused by an address error or possibly a different issue (stack overflow, hardware divison by zero). |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
