Why - No source available for "g_pfnVectors() at 0x0"

[martinnovotny]

Using LPCOpen, LPC1549... Everytime I debug any project (my or imported from lpcopen_2_20_lpcxpresso_nxp_lpcxpresso_1549) I got "a message" No source available for "g_pfnVectors() at 0x0". It doesnt matter whether I debug it in LPCExpresso or MCUXpresso. It seems it doesnt limit me and all works fine but why it has allways appeared?

I havent found out any topic with this issue but I cannot believe nobody has the same "problem".

Any Idea what does it mean?

[martinnovotny]

Ok, I think I got it so I thank all of you for your replies !

[lpcxpresso_supp]

This is pretty much as Erich explained. 

That message is basically erroneous. The debugger has at some point of during the connection to the target tried to access memory at a point when the PC was not "valid", and then tried to display the source related to the "invalid" address - which has triggered the edit box with the"no source..." message in it. Preventing this happening is actually very hard, as it depends on all sorts of configuration and timings between the PC, the debug probe and the target. And many users won't actually see it in their particular setup.

But as you have said, this doesn't actually stop debugging. Just close that particular edit box, and potentially click on the "main" in stack frame displayed in the Debug View at the top of the screen, and you should then be back in business.

Regards,

MCUXpresso IDE Support

[martinnovotny]

Ok, probably I dont understand well what the source means. I thought that a constant table (array g_pfnVectors[]) is source as well. Could we say there is a source at particular adress only when there is an instruction at the same address? And any constant or number or whatever else is not source?

[bernhardfink]

Yes, this is maybe the right way to see it. If you are on an ARM instruction in the disassembly window, then you will also have a corresponding C-code instruction in the source window.

When a debugger loads an image it also considers the constants, tables, variables etc in order to display this data in other windows (variable view), so I don't consider this as source.

Regards,

Bernhard.

[BlackNight]

To my understanding, this is what happens:

- debugger downloads the application

- PC (Program Counter) is set to 0

- GDB reports zero as the current program counter to the IDE

- The IDE tries to find the source file for that code at address 0

- because there is no source file for this, it shows that dummy message

In the past I had scripted some extra gdb commands to get around this, but I have to check if this is still applicable to the latest gdb/Eclipse.

I hope this helps,

Erich

[martinnovotny]

Ok, but I think there is a source file (in this case cr_startup_lpc15xx.c) or isnt? And why the IDE or debugger continue to hit main() and all works well? Does it mean everybody who works with LPCOpen or these IDEs is annoyed by this dummy message continuously? And why dont NXP experts remove this behavior?

[bernhardfink]

I don't see source code for g_pfnVectors, only a constants table. These are 32-bit words, containing addresses for the exception handlers and the interrupt service routines. 

You're right, there is a source file, but in the function g_pfnVectors() there is no  C source code.

Nothing the debugger could show as source code. However, the error message in this case it not very meaningful.

Regards,

Bernhard.