SDK 2.2 RC3 broke my application

[tjrossi]

Can anyone decipher this? The application (that works fine under the old sdk) worked for a short period of time and then started crashing with no stack dump. After a while it degraded to the trap below and now I cannot update the board software to a safe application via the serial terminal....

Thanks,

Trevor

Trap occured
Vector=Access Error FMT =03 SR =2710 FS =0C
Faulted PC = FFC03D40
D0:00000007 0000003F 0000003F FFC7FCAD 02000000 00000000 91C61551 13B010F7
A0:FFC80000 02102EF4 02102EFC 2000FE3C 0000003A FFC00512 2000FE20 2000FE00
Waiting 2sec to start 'A' to abort
Waiting 2sec to start 'A' to abort

Trap occured
Vector=Access Error FMT =03 SR =2710 FS =0C
Faulted PC = FFC03D40
D0:00000007 0000003F 0000003F FFC7FCAD 02000000 14E1AF0A 91C61551 13B010F5
A0:FFC80000 02102EF4 02102EFC 2000FE3C 0000003A E3DA3D6B 2000FE20 2000FE00
Waiting 2sec to start 'A' to abort

Trap occured
Vector=Access Error FMT =03 SR =2710 FS =0C
Faulted PC = FFC03D40
D0:00000007 0000003F 0000003F FFC7FCAD 02000000 14E1AF0A 91C61551 13B010F5
A0:FFC80000 02102EF4 02102EFC 20000640 0000003A E3DA3D6B 20000624 20000604
Waiting 2sec to start 'A' to abort


Netburner MOD5282 Monitor V1.13 Dec 6 2005 14:35:59
HELP for help
nb>Waiting 2sec to start 'A' to abort

Trap occured
Vector=Access Error FMT =03 SR =2710 FS =0C
Faulted PC = FFC03D40
D0:00000007 0000003F 0000003F FFC7FCAD 02000000 1050A10A 91C61551 13B010F5
A0:FFC80000 02102EF4 02102EFC 2000FE3C 0000003A 63CA3D2A 2000FE20 2000FE00
Waiting 2sec to start 'A' to abort

Trap occured
Vector=Access Error FMT =03 SR =2710 FS =0C
Faulted PC = FFC03D40
D0:00000007 0000003F 0000003F FFC7FCAD 02000000 1050A10A 91C61551 13B010F5
A0:FFC80000 02102EF4 02102EFC 20000640 0000003A 63CA3D2A 20000624 20000604
Waiting 2sec to start 'A' to abort

Trap occured
Vector=Access Error FMT =03 SR =2710 FS =0C
Faulted PC = FFC03D40
D0:00000007 0000003F 0000003F FFC7FCAD 02000000 1050A10A 91C61551 13B010F5
A0:FFC80000 02102EF4 02102EFC 20000640 0000003A 63CA3D2A 20000624 20000604
Waiting 2sec to start 'A' to abort


Netburner MOD5282 Monitor V1.13 Dec 6 2005 14:35:59
HELP for help
nb>

[tjrossi]

Well, I managed to get a clean application onto the board. A co-worker let me in on the secret about aborting the boot ('A') before the first trap...

Now the debugging can start...

[lgitlitz]

What is the release version of your old NNDK? What types of functions are you using from the NNDK? Are you directly accessing the processor SRAM in your application?

[tjrossi]

Upgrading from NNDK 2.1, I believe. It was the previous released version before the 2.2...

I am not using processor SRAM.

My application is C++ and uses the TCP library, amongst other things...

I have isolated the problem in my application. It appears that if I try to read or write a large chunk of data (between 6k-50k) to/from a TCP socket, the entire program crashes/halts/locks up (according to the debugger, it appears it is either a SIGSEV/SIGILL at the next context switch after the read/write).

This worked fine in the old NNDK.

I have been able to reproduce the problem in a stand alone application using only NetBurner libraries. Attached is a program that has the described behavior.


Thanks,

Trevor

[lgitlitz]

I didn't test this code but I see an error. The char buffer[buffer_size]; declaration is local, so it is put in the task stack. Our default task stack size is only 8K but the buffer is 10K. The main stack is now placed in SRAM by default. The data right before this stack is the idle stack. When you overflow the main stack you are modifying the top of this idle stack. This will likely lead to strange sudden traps or lockups next time the idle task is reached, hence the context switch lock-up you are seeing.
The reason you didn't see this error in the old build is likely due to luck. The data before the main task might have just been un-allocated memory so over-running it would have not triggered an error.

Make this buffer global so it will not be placed in the task stack.

-Larry

[tjrossi]

Thanks, Larry! That took care of it. I had initially thought that might have been the problem and dynamically allocated the send buffer in my application, but I neglected to 'new' the receive buffer, which was the problem.

Trevor