getting mplab XC32 to grasp that this is C++ not C

[cv007]

I take it you mean that you remove the sram linker script from the project

I don't get the sram script in mine for the samc, but I think I created a test project earlier in this thread for a pic32c-something and had both. Don't know why the sram one would show up.

In the call stack right before the crash handler the last entry is <Signal Handler Called>: 0xFFFFFFF9

I am assuming nothing is there?

I would guess you have a missing/misnamed handler where you are now ending up in the default handler when the can irq fires. If it was something else you would not be seeing the can irq number.

[newbrain]

In the call stack right before the crash handler the last entry is <Signal Handler Called>: 0xFFFFFFF9

I am assuming nothing is there?

If by "nothing is there" you refer to the 0xFFFFFFF9 value, note that this not a memory address.
It's way the arm core knows it must return from an exception rather than from a regular call - a special marker placed on the stack (after saving part of the CPU state) when an exception is entered.

How exceptions work on a cortex-m0+ is explained in the ARMv6-m Architecture Reference Manual, chapter B1.5, specifically, the values left on the stack by an exception are described in "B1.5.8 Exception return behavior".

Cortex-M0+ being quite simple, only three different values are used, depending on which mode (Handler/Thread) and stack (Main/Thread) are selected upon return (the missing combination is Handler mode with Process stack, which is not meaningful).
More sophisticated cores use a wider range of values, including flags for FPU use, secure state, etc.

Moreover, as the area 0xE0000000-0xFFFFFFFF (named "System", chapter B3.1) can never be executable, there is no risk for ambiguity with a possible real return address.

[cv007]

...adding to that, you will have information on the stack- r0-r3,r12,lr,pc,xpsr  which you can look at to see where you came from (pc). In this case I would suspect it would be of no help since it appears this is a normal exception which could have taken place anywhere. If you end up in the hard fault exception as an example, the pc on the stack usually points to the code which caused the hard fault (unaligned address, bad address, etc.).

For my stm32 which I use no debugger, I have an error function in the startup file (like a default handler), which saves this stack info to some (noinit) ram set aside to store debug info. After the subsequent reset my main app can print out the debug info if wanted. Not needed very often but sometimes you make errors which usually show up right away, and with the pc info you can usually get the address of the problem code and get things sorted out quickly.

As already mentioned, enable the lss outout in the project settings. Get good at reading the lss file which is useful for debugging. In your example, assuming you're pretty sure the can handler function is in place and correctly named, the first thing I would look at is the lss listing, specifically the vector table entry for this irq. Its not going to be spelled out for you, but its easy enough to figure out where this entry should be (and of course you are looking at little-endian u32's). That address either points to the default handler or your can handler, and would guess it points to the former.

[bson]

What debugger is used?  If gdb, then properly set up for the architecture it will unwind and print exception stack frames correctly.  If it doesn't, then it likely doesn't have precise target information, like it only knows it's ARM thumb and not specifically CM0+.  This should be embedded in the executable (not necessarily loadable image) by the compiler and linker.  Or passed as an argument, or put in an init script.

[Simon]

Well I think the issues are now in the realm of my own code. Now I have a call stack to look at whereas before it was just going to hard fault. The CAN IRQ could be coincidental as now there is a function listed right before this signal address. The function runs every 500 ms to transmit a heartbeat message. I fixed some errors I found in my code but now I also see that and array of void pointers is not showing up as having any indexes in the variable watch window. I was using a J-Link compact plus.

[Simon]

The CAN bus interrupt fires on any received message or when the timestamp counter overflows every 5ms.

[Simon]

Well, I've spent the weekend playing with VSCode. I have not one but two blinking LED's on a PIC32CX1025SG41128 with debugging via the J-Link plus compact.

When it comes to Ozone I am stumped. I can load and run a program, that is if I set the reset to the vector table and not the elf entry point which is the default. Using the default means that it ends up in a hardware fault at our favourite address 0xFFFFFFFE. But if I set it to what is basically 0x00000000, it loads a program and runs and can be halted and the registers interrogated.

But having run through half the enormous manual for the lack of information in it is staggering so far. I'm still trying to work out how to do anything like debugging with the source files.

[voltsandjolts]

When it comes to Ozone I am stumped. I can load and run a program, that is if I set the reset to the vector table and not the elf entry point which is the default. Using the default means that it ends up in a hardware fault at our favourite address 0xFFFFFFFE. But if I set it to what is basically 0x00000000, it loads a program and runs and can be halted and the registers interrogated.

FWIW I did try to give you a heads up on that.
https://www.eevblog.com/forum/microcontrollers/getting-mplab-xc32-to-grasp-that-this-is-c-not-c/msg6161533/#msg6161533

But having run through half the enormous manual for the lack of information in it is staggering so far. I'm still trying to work out how to do anything like debugging with the source files.

Are you compiling with the -g option to put source file paths into the ELF so Ozone can load them automagically, like I mentioned in that linked post?

[Simon]

Ah, yes. I did have -g to get things working in VSCode, so now it works in Ozone too.

[Simon]

In VSCode the paths in launch.jason for debugging had to be entered manually rather than use the workspace definition of the project folder as on VSCode in windows it uses "\" between folders rather than "/" and the path is then interpreted as one whole word with the "\" removed by the debugger software so it never finds anything. So the Ozone program will be easier to use.

I believe the "\" versus "/" is a windows/linux difference. In fact it felt like the whole process would have been simpler on Linux or maybe it is just that my make file was written for linux or for things I do not have on my windows machine and there were lots of changes to be made by copilot.