Target Exception - Exception in Kernal Task

[Thxe]

Hello, I'm still trying to get the Simple Template to work on our robot. I am able to successfully load the program to the robot, however I get the following error message:

VxWorks6x_10.25.35.2: Exception in Kernel Task FRC_RobotTask:0x133bd60 at pc=0x8

Vector 0x700: Program Exception  status=0x0

The debugger is already attached to debug this exception.

I am using the following settings

Main
entry point FRC_UserProgram_StartupLibraryInit
no arguments
priotity:100
Stack size: 0x20000
Advanced Options: {Options=0x10000010}

Downloads
SimpleTemplate.out Symbols(check) Reload(uncheck) Options:-plugin:nounload

Common
Debug(check)

Thxe

[ShadowoftheSun]

We have the same issue intermittently, and with different code bases.

At the moment, our robot is stuck in "Task" mode and awaiting a reformat...


Anyway, do you have the "break on entry" box checked on the debug settings dialog? If so, does the program execution successfully pause before you experience an exception, or is it immediate?

[katyrobo2177]

We are having the same issue with debugging. Does anyone have any ideas on how to fix it??

[gvarndell]

Originally Posted by Thxe

Hello, I'm still trying to get the Simple Template to work on our robot. I am able to successfully load the program to the robot, however I get the following error message:

VxWorks6x_10.25.35.2: Exception in Kernel Task FRC_RobotTask:0x133bd60 at pc=0x8

Vector 0x700: Program Exception  status=0x0

The debugger is already attached to debug this exception.

I am using the following settings

Main
entry point FRC_UserProgram_StartupLibraryInit
no arguments
priotity:100
Stack size: 0x20000
Advanced Options: {Options=0x10000010}

Downloads
SimpleTemplate.out Symbols(check) Reload(uncheck) Options:-plugin:nounload

Common
Debug(check)

Thxe

I'm afraid this won't be much help but a little insight perhaps.
Vector 700 means the CPU has encountered an illegal instruction.
If what you pasted above is not truncated, and the program counter (PC) was indeed 0x8, then somehow the CPU jumped to (most likely) code address zero.
How would that happen?
If you loaded a module that wasn't fully and correctly linked (unresolved externals) then that code would very likely end up making a function call to address 0.
Of course, there are many other ways this can happen -- including stack overflow or corruption.
And C++ makes this more interesting because it invites some devilishly clever ways to end up executing at an invalid address.