No source available for "0x0" -- execution stops at __isr_vector()

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

No source available for "0x0" -- execution stops at __isr_vector()

3,710 Views
dave408
Senior Contributor II

I have read the existing post No source available for "__isr_vector() at 0x0" but the solution there did not work for me, so I am really hoping that someone here has some debugging tips for me!

My current firmware (developed under KDS 3.0 with KSDK 1.2) was generally working fine, but today I had to add another OS_Task.  It is during debugging of this task that I ran into trouble, including this problem where my code stops executing and all I see is this:

pastedImage_3.png

I thought that maybe it was a task stack size issue, but I have increased the stack size already.  The code fails roughly at the same point every time.


I know that I am not having a power supply problem.  I did find it strange that every time this error occurs, I have to unplug my Segger J-Link, or upon the next execution attempt, it will not see the debugging device.  I originally had it plugged into my monitor, so I switched to my front USB ports.  When that didn't work, I tried my rear USB port through a powered USB hub.  I still have the same problem.

The place where execution stops is really weird.  It's when I assign NULL to a member variable:

pastedImage_4.png

Seems innocuous enough to me.

Can anyone recommend other things to try here?  I'm going to try reverting the code back a little and running some tests outside of the task to see what happens.

EDIT - I removed the task and reran code that used to work, and it now fails when evaluating a simple for loop.  I'll probably have to revert my entire codebase now -- maybe there's something in the shared classes that is screwing up everything...

0 Kudos
5 Replies

1,925 Views
martinmadron
Contributor II

Hello,

i think it happens when your breakpoint is not on the line with code. Every time that happens, removing odd brakepoints will remove problem for me.

0 Kudos

1,925 Views
dave408
Senior Contributor II

Thanks Martin -- I have this problem even if I do not have any breakpoints set.  I have seen what you're describing, but I think in that case you don't get the __isr_vector() problem, but instead arm-none-eabi-gdb.exe will crash.

0 Kudos

1,925 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

can you also try same with KDS 3.0 with KSDK 1.3?

how does it work?

if problem still exists, can you please share how to reproduce your problem step by step?


Have a great day,
Zhang Jun

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,925 Views
dave408
Senior Contributor II

Unfortunately, the problem has gone away.  Actually, it's not really unfortunate, but it would have been good to know what caused it.

It's very possible that it was an electrical issue.  One other problem I was having was that my K22F board would not execute code unless the J-Link was connected to the board.  As soon as I unplugged it, the board would stop running.  It turned out that the pin on the ground pin to the board wasn't pressed into the housing all of the way, and it worked itself loose.  The JTAG connection would provide the ground and then allow the board to boot.  So since I've only ever seen the __isr_vector() issue in the past when I loose power, at this point I'm going to blame this weird problem on power draw or something else that's happening when I execute code and control peripherals on the board.

0 Kudos

1,925 Views
dave408
Senior Contributor II

This seems to be a debugger-specific problem to me.  If I detach the debugger and just let my firmware run, it continues to process commands fine, even the one that causes the debugger to stop at __isr_vector().  Hopefully, someone will be able to explain to me what might be happening here.  I have no idea where to go from here.  I really need to be able to debug this firmware still, but if it keeps stopping execution like this, I'm going to have a miserable time with it.

0 Kudos