Page 1 of 1

MOD5282 SmartTrap not working

Posted: Wed Aug 20, 2014 8:32 am
by sulliwk06
When I enable smart traps and cause a trap, I'm only seeing the device reboot, I'm not seeing the smart trap output. I'm connected to UART0 which is set as the debug port, I'm not in debug mode. I don't actually see the trap like I normally do when smart traps are not enabled, so I think it's working but I'm not seeing the output. I tried the same experiment on my NANO54415 and the smart traps are working, so why not on my 5282?

P.S. I couldn't seem to cause a trap using the smart trap example in the NetburnerPCTools doc, so I just wrote a recursive function to blow the stack

Code: Select all

volatile int BlowStack(int depth)
{
	int stackVar = depth+1;
	iprintf("\r\ndepth = %d", stackVar);
	return BlowStack(stackVar);
}

Code: Select all

Blowing Stack
depth = 1
depth = 2
.
.
.
depth = 34
depth = 35
depth = 36
depthWaiting 2sec to start 'A' to abort

Re: MOD5282 SmartTrap not working

Posted: Wed Aug 20, 2014 9:10 am
by dciliske
Are you running a debug build?

[Edit: Never mind. Reading comprehension failure... Somehow I passed that in elementary school...]

Re: MOD5282 SmartTrap not working

Posted: Wed Aug 20, 2014 11:18 am
by pbreed
Blowing the stack will not always cause a trap....


Try a divide by zero...


IE
void DoTrap()
{volatile int i;
i=1;
i--;
i=10000/i;
}

Re: MOD5282 SmartTrap not working

Posted: Wed Aug 20, 2014 12:36 pm
by sulliwk06
pbreed wrote:Blowing the stack will not always cause a trap....

Try a divide by zero...
Wow, ok I guess the smart traps are working, I'm seeing them now. The problem is this all started when I was getting a trap on an OSSemPend which confused me, so I turned on smart traps and then the device would reboot instead of trapping. I guess I'll have to find another way to track this down.

Thanks for your help.

Re: MOD5282 SmartTrap not working

Posted: Wed Aug 20, 2014 1:34 pm
by dciliske
I would bet that means your having a memory corruption issue. Trapping on a SemPend implies that someone's stack frame is corrupted and that restoring from that state caused a problem when resuming.