Home/Support/Support Forum/Abort Exception
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Abort Exception

0 votes
I am getting following exception- Please let me know the cause of it.How to avoid this Abort Exception?Thanks in advance.

Abort Exception
CONTEXT: THREAD
Thread Name: HSV
Thread ID:54485244
Thread Stack Start Address:00375908
Thread Stack End Address:00378107
Program Counter :0811AE08
Stack Pointer :042B1EB0
Current program status Register :00000097
R00:A0000000 R01:00000093
R02:0000003F R03:A0000013
R04:BC3A2052 R05:0000000B
R06:00000001 R07:00000800
R08:00000000 R09:0000000B
R10:00000000 R11:00377FA4
R12:00377F4C
asked Aug 9, 2011 in NET+OS by GKM New to the Community (1 point)
recategorized Nov 26, 2013 by tuxembb

Please log in or register to answer this question.

5 Answers

0 votes
Hi,
Is it NET+OS? did you try recovering the device?
Explained in Help Docs.
Digi ESP for NET+OS User Guide > 2. Tasks > 2..7 Recovering a NET+OS Device
??
answered Aug 10, 2011 by bobthomas13 Seasoned Professional (182 points)
0 votes
Yes, It is NET+OS. I am getting this while sending a string on Serial Port 2. (in Debug mode).
answered Aug 10, 2011 by GKM New to the Community (1 point)
0 votes
Check your code itself.. Could be some pointer access issues. Which NET+OS version are you using? make sure you have all latest updates.
After updating you have to start ESP with "-clean" and create a new project , copy all your relevant files.
rebuilding will not help as the updates won't update existing workspace.
answered Aug 10, 2011 by bobthomas13 Seasoned Professional (182 points)
0 votes
Hmmm interesting.

Thread name HSV refers to the web server (AWS). Generally an AWS crash would be associated with a "stub" function. Take a cloise look at your stub functions and ensure that your pointers are ok and that you are not writing off the end of a string or buffer.

You should also look at your root stack and ensure it is large enough.

Getting back to yoru stub functions, do you define a large amount of stack memory in your stub functions? Doing so could blow the web server's stack space.
answered Aug 13, 2012 by dakotas_dad Veteran of the Digi Community (694 points)
0 votes
Abort Exception means almost always corrupted memory, especially if it happens in system code and not in your own. Are you able to reproduce this in the debugger?
in that case:

You can put breakpoint in inti.s– use DIGI ESP debugger’s console (it’s a regular gdb console actually and it accepts regular gdb commands)
Use commands:
b Undefined_Handler
b SWI_Handler
b Prefetch_Handler
b Abort_Handler
b Address_Error_Handler
b crash

etc to set breakpoints
Once you will get an exception , you will hit one of those breakpoints and you will know what exception did you get. Once this happens, look at the link register (LR) - go to the instruction that is on address pointed by the LR - you may have to switch to mixed mode where both C and assembly language instructions are displayed. Once you there, put a breakpoint on the previous instruction - this is the line that caused look and try to figure what this instruction is doing. If it is not HW exception, you can look at the call stack when you hit your breakpoint at customizeExceptionHandler() and try looking at the call stack at this point in DIGI ESP.
answered Aug 14, 2012 by LeonidM Veteran of the Digi Community (4,010 points)
...