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

[uer166]

Oops. Yes I am, ignore that late night comment!

[Simon]

Which of the J-links exactly were you refering to? they range from $200 to $1000+. I have gone round this circle before.

I would recommend the j-link plus as it's the cheapest option which has an Ozone license.
https://uk.farnell.com/segger/8-19-28-j-link-plus-compact/debug-probe-1mbps/dp/3106582
https://www.ebay.co.uk/itm/257179833926

Not my ebay listing BTW!

But you can use any j-link to evaulate Ozone and other Segger software and decide if it's for you.

So I cracked and ordered it. Looks like a good deal, I need to start somewhere anyway and I can see that trying to use the waveshare USB/JTAG adapter is just going to be a nightmare to setup.

[voltsandjolts]

Congrats on your first test equipment purchase of 2026

Software download;
https://www.segger.com/downloads/jlink/

The j-link pinout is here;
https://kb.segger.com/20-pin_J-Link_Connector#Pinout_for_SWD

If you use j-link commander to setup the virtual comm port, you also have UART TX/RX shown here;
https://kb.segger.com/20-pin_J-Link_Connector#Pinout_for_SWD_+_Virtual_COM_Port_(VCOM)

Note the VTref input which needs connected to your circuit Vcc, to set logic drive level. Alternatively, you can software configure it at 3.0V or whatever.

You can use jumper wires to get going with but Segger has a bunch of adapters;
https://www.segger.com/products/debug-probes/j-link/accessories/adapters/overview/

I've mostly standardised on using a JST ZH 1.5mm pitch connector for swd and made a custom adapter pcb for it. Picture shows it with an STLink but its same pinout as j-link. So if you want a custom adapter I can make something for you quite quickly.

[Simon]

I tend to use the 1.27mm header. The Pickit adapter board looks like it will take a cable from the j-Link and then it is adapted to 1.27mm 10 pin JTAG. I've got to be backward compatible anyway.

[voltsandjolts]

adapted to 1.27mm 10 pin JTAG

Remember it's the SWD connections I linked above (rather than JTAG) that you'll need for the ATSAMC21J17A.

[Simon]

So the J-link compact plus has arrived. The only example they give for VSC uses some uses an off the shelf dev board for ST with a downloadable project:
https://kb.segger.com/J-Link_Visual_Studio_Code#:~:text=The%20J%2DLink%20installation%20directory,Debug%20and%20C%2FC%2B%2B%20IntelliSense.

Is it "just" a case of adapting the jason script to my device?

Are there other IDE's that just work? I know Segger have their own IDE.

[eutectique]

Are there other IDE's that just work? I know Segger have their own IDE.

Ozone

[voltsandjolts]

Are there other IDE's that just work? I know Segger have their own IDE.

As eutectique says, Ozone is Segger's debugger and I find it very good. It means I can use any text editor I want, then use Ozone as the programmer/debugger. This way I can avoid IDEs and have a more portable skill set, because Ozone works with all the mcu's I will work with, from a range of manufacturers.

Yes, I'm sure you can setup VS Code for ARM debugging and use the Segger probe (and Segger dll's) but I don't know how. It would probably result in a debugger inferior to Ozone anyway 

Try Ozone first and see how you like it. Once you have an Ozone project setup and running (about 1 minute to do**), it will offer to load the new ELF after a build and away you go. The debugger is just an ALT-TAB away.

Make sure to build with -g or -g3 (and -O1 say) to get all debug info into the ELF, Ozone will get the source file paths from there.

** Gotcha for folks new to Ozone, when using new project wizard, for ARM you probably want to select "Initial PC : Read from base Address Vector Table", rather than the default first option, as per pic;

[eutectique]

I found -g3 -Og to be the most convenient combination of options. You get all symbols, including #define's; the code is reasonably optimised to fit the flash and yet debuggable.

[Simon]

OK, so I need to get off MPLAB.X anyway as an editor, it's atrocious. I never got it to work properly on a 4k screen and it gives me a headache. I have been moved across several laptops over the last few months as we have had an epidemic of failures and I have noticed varying results with different laptops but never really got it sorted out. It's also just a pain in the ass to work with.

So I have potentially 2 solutions to set up to work side by side. Is VSC a good idea? Visual Studio seems to be a very good IDE, is that feasible? This will be a load of work as I'll also need to get into the whole make file stuff and getting in control over the tool chain. So I'll try not to repeat myself.

[langwadt]

OK, so I need to get off MPLAB.X anyway as an editor, it's atrocious. I never got it to work properly on a 4k screen and it gives me a headache. I have been moved across several laptops over the last few months as we have had an epidemic of failures and I have noticed varying results with different laptops but never really got it sorted out. It's also just a pain in the ass to work with.

So I have potentially 2 solutions to set up to work side by side. Is VSC a good idea? Visual Studio seems to be a very good IDE, is that feasible? This will be a load of work as I'll also need to get into the whole make file stuff and getting in control over the tool chain. So I'll try not to repeat myself.

https://adamsiembida.com/how-to-compile-mplabx-projects-from-the-command-line/  to get a makefile and you are mostly done?

[voltsandjolts]

Is VSC a good idea? Visual Studio seems to be a very good IDE, is that feasible?

I use VSC as an editor, and for my simple requirements it's good. Folks say its source control features are quite good, but I use a seperate program (sourcetree) for that. Maybe try this combo;

VS Code (as an editor, without debugger, KISS)
Makefile to build
Ozone to program/debug

[bson]

If you don't mind learning gdb there's Black Magic Debug, https://black-magic.org/, which has a gdbserver on it, eliminating any need for openocd or such.  Just run gdb, directly or through VSCode, and connect to it.  The gdb can used to program the target.

gdb has some really excellent functionality, like being able to type C/C++ expressions including casts.  So you can look at say an I/O buffer, check a type prefix, then cast it to a struct of the payload type.  It does pointer arithmetic, array subscripting, etc.  Plus it's programmable in python and scriptable in tcl.  The latter can be used for more complex things like dump the entire firmware state in a human-readable format, or perform invariant checks (basically look for invalid states or combinations of states).  Because it can work against images (originally intended to analyze Unix core dumps) you can also take a complete dump of the target and the examine the images with gdb.

[Simon]

So I have wasted a week with mplabx. So to cut a long story short. If I use the XC compiler I can't control the stack allocation. It looks like it assigns all remaining RAM but it doesn't and according to another number in the project properties it assigns nothing which is impossible. To be able to actually control it you have to have a licence.

Meanwhile with GCC they deny you access to the linker files and won't listen to the stack size you put in it if you find it and try.

My program uses 4-5kB of RAM and my chip has 16 kB but the stack seems to be 1KB denying me use of over 50% of the RAM I PAID FOR. Fucking cunts!

Is the segger embeded studio any good? I am about ready to tell my employer to pay up or I walk.

[ejeffrey]

For what it's worth, the "stack allocation" is usually just for compile time checks anyway.  The linker will complain if code+data+bss leaves less space for the stack than is requested.  But there are no runtime checks so you can use more than that as long as you dont have a stack collision.

[Simon]

First I had data being written to beyond the 128kB of the flash, this is silly as the program was well under half that. Then I tried increasing the stack and could not. So now I'm even more clueless. I can't trust MPLABX so I have no idea what is going on.

[cv007]

To be able to actually control it you have to have a licence.

Are you using XC32? I use MPLABX but use the gcc toolchains for avr and cortex-m downloaded from other sources. Download gcc directly from Arm, extract it somewhere, then in MPLAB embedded options add a new toolchain pointing it to the gcc bin folder. You then have the option to choose this compiler instead of XC32. I have never used XC32 for cortex-m (samD), but if its like their XC8-AVR version the compiler options in the ide are limited. When using gcc (not XC32) you get the options you expect.

It appears the ide will create a couple linker scripts- flash/ram, and also a couple c files system/startup. I believe these are one time creations and are 'yours' to do with as you wish, including deleting the ram linker script. The linker scripts have defines they optionally use (such as STACK_SIZE or __stack_size__, HEAP_SIZE, etc.), so you can pass defines to the linker which allows some changes via this scheme but you also have the whole linker script which you can modify directly as you wish.

For stm32, I use the gcc toolchain from arm, vscode for editing, and a makefile (in Windows I just have a make.exe file to handle the makefile, I think I got it from tcc/busybox). Programming is done via the makefile copying the bin file to the st-link virtual drive. Debugging is done via uart output, and/or simply looking at source code and asm output to figure out any problems. The makefile requires very little work once in place and it simply becomes a collection of options. My favorite setup, which is also quite portable.

[Simon]

So where are the RAM and flash linker files stored? I found the ones in one of the device packs and tried selecting that older device pack and changed the stack allocation. It was completely ignored by MPLABX.

So I just created a blank project with the ARM toolchain selected and now I see the linker files in the project. before I must have started the project as a XC32 one and it did not put them in for my editing pleasure.

[cv007]

For what it's worth, the "stack allocation" is usually just for compile time checks anyway.  The linker will complain if code+data+bss leaves less space for the stack than is requested.  But there are no runtime checks so you can use more than that as long as you dont have a stack collision.

I believe in the case of the MPLABX generated linker file the stack size becomes the max size the stack will use (startup uses _estack for the vector table stack entry, which is the stack section end address). In other words, any unused ram above the stack section will remain unused.  You will also get the stack section counted as used data and can be an unwanted thing- I think its nicer to see the stack space as free ram so you can always get an idea of the data/bss/(heap) space in use separate from stack space (free).

If no heap is wanted, I would set the default heap size value in the linker script to 0. If you want the heap, then pass the heap size define to the linker. You still get the heap symbols in any case but by default there will be no heap available and will not show up in data usage. If the heap is put to use (maybe unknown to you), malloc will fail as there is no heap space, but would be a runtime failure (this assumes you have the specs in use that provides _sbrk, and also assumes the linker script has defined the 'end' symbol which _sbrk uses, so you may be prevented from using the heap at compile time).

For the stack, you can remove the stack section, and instead place the following lines at the end of the linker script-

_estack = ORIGIN(ram) + LENGTH(ram);
ASSERT( (_estack - _eheap) >= STACK_SIZE, "STACK_SIZE too small" );

The _sstack symbol will be eliminated but is most likely unused plus the _eheap symbol is the same value and will still be available. This puts the _estack symbol at the end of ram (startup code vector table stack entry value), and also asserts you have at least the stack size you requested (or its linker script default value). The stack space is also now not shown in data usage, but all free space will be available for the stack.

[westfw]

That's sort-of the problem with "IDEs" - they hide too many things from the developer, pretending that it makes things easier.   But it's only easier 80% of the time, and when you hit that 20% where you need to change some hidden behavior, you find that:

• The needed commands/etc are buried deeply in some obscure control panel or configuration file.
• They're no less complicated than they would have been without the IDE.
• But since you've been coddled "up till then", you're not familiar with the parts you need to manipulate.

You see this all the time with Arduino users who have hit some wall: "What do you mean I can't (easily) change the optimization level of the C++ standard?"

But other IDEs just have the wall in different places.  "How do I change the stack size?" is a good example.  (It seems many ARM compile environments have a defined stack, instead of the 8-bit "start at the top of memory" approach.  (Maybe because they originated in "microprocessor" environments rather than "microcontroller" environments?  or because of the possibilities of using MPU to detect over/underflow?))

In general, when I run into problems like this, I look closely at the actual commands and the binary that the IDE is generating, where there MIGHT be some parameter to set things, and then I go backwards to figure out how to set or override it.  Except this is sometimes more difficult than, say, reading the gcc documentation on how to do the thing I want...

For the stack issue, a test MPLAX XC32 SAMD20 project I setup has a "Minimum Stack Size" parameter in the xc32-ld project panel whose help says:

Specify the minimum size of the stack in bytes. By default, the linker allocates all unused data memory for the run-time stack.
Alternatively, the programmer may allocate the stack by declaring two global symbols: '__SP_init' and '__SPLIM_init'.
Use this option to ensure that at least a minimum sized stack is available.
The actual stack size is reported in the link map output file.
If the minimum size is not available, an error is reported.

The .map file produced includes a variable "stack", but it is the "bottom" (low address) of the stack, rather than the initial SP, and I don't see variables for the "top" or initial stack pointer (which is sort of annoying.)

[cv007]

a test MPLAX XC32 SAMD20 project

Most ide's for cortex-m do not use modified versions of gcc, so you will normally get a linker script file you can tailor to however you want and jumping between different mcu manufacturers will result in things being mostly similar. With xc32, which doesn't seem to provide/use a linker script per say, you are maybe stuck with whatever scheme they decide is 'best' as their version of the linker is doing something different than the normal gcc.

So, I would not put the 'IDE' necessarily at fault but in this case would lay any blame on xc32. I have used MPLABX since it came out, and generally do not have a problem with it, but I do not use xc8-avr or xc32 compilers so am not dealing with their non-standard compilers. Using the standard versions of gcc means you will have consistent usage no matter which manufacturer's name is on the mcu. As mentioned I prefer a simple makefile, an editor, and the command line, but can also easily make MPLABX do what I want even if not preferred.

[Simon]

I can't test this until I am in the office tomorrow but the problem could be that I started with XC32 then moved it to GCC. This means that the linker file was not put into the project so I still could not control it.

There are two problems here. The first was that the flash was being programmed beyond the end of the flash according to the build. Garbage collecting seems to have stopped that error. The second issue that I can't even prove is that I needed to allocate more stack. Assuming they listen to the linker file in a GCC project I can control that now. It's not the first time I have had to increase stack to stop issues.

MPLABX seems to really not get that one may program in C++ (or at least object oriented C in a syntax that makes sense).

I am not using any C++ library, the only C++ features that I am using is classes and function overloading so I do not believe that any heap is needed? I create all objects statically outside of any function and expose them via header files if any other file requires it.

I am currently using Alex Taradov's starter projects in VSCode to try and set up my own system where I can control things. So I have learnt something of the make and linker file syntax. Then it will be the fun of using the J-Link plus compact to program. I don't know how debugging works in VSCode but it's time I got out of this microchip rut.

I don't actually understand why there is a XC32 compiler. From the sounds of it it is microchip trying to rip people off by charging them for full access to the GCC compiler having put limitations on what it can otherwise do whilst making it harder to control GCC.

[Simon]

As Alex's files don't contain any project for (cough splutter) microchip parts I am using the SAME54 as a basis for creating a starter project for the PIC32CX1025SG41128 as I do have a dev board for that with me as it is the newer chip I am starting to use. I have downloaded the "pack" for the PIC32CX-SG series and there are 2 linker files for each chip, *_sram.ld and *_flash.ld. Copilot in VSCode tells me that only one is required and that the sram one is for debugging so that code runs from RAM. OK, so how does a potentially 1MB program run from 256KB of RAM?. Is this something beyond the debugging that I do with MPLABX and the PICKIT 5 ?

the only real difference I see is that the sram one has this code at the end:

Code: [Select]


/* .ARM.exidx is sorted, so has to go in its own output section.  */
    PROVIDE_HIDDEN (__exidx_start = .);
    .ARM.exidx :
    {
      *(.ARM.exidx* .gnu.linkonce.armexidx.*)
    } > ram
    PROVIDE_HIDDEN (__exidx_end = .);



[Simon]

Well slowly getting there, but I have an error from the compiler (C++17)

../include/core_cmFunc.h:414:21: warning: ISO C++17 does not allow 'register' storage class specifier [-Wregister]

This is since C++11

According to VSCode "register" expands to : "typedef unsigned long uint32_t" which to me just sounds nuts.  I thought a register was if anything "volatile" ? I'm assuming that the intelli-sense is showing that register is a uint32_t type that is basically a typedef derived from unsigned long.

[cv007]

the only real difference I see is that the sram one

The difference is that all the sections are being put in the ram region,  > ram

Just delete the ram linker script. You are not going to wear out the flash anytime soon, which is probably the original reason for this scheme. There may be uses for it, but you are not going to need it.

MPLABX seems to really not get that one may program in C++

MPLABX does not care whether you use C/C++, but XC32 may have ideas about that. Except for maybe an initial omission of handling the .cpp extension in MPLABX settings, it handles C++ just fine (that's all I use in MPLABX).

so I do not believe that any heap is needed?

You can tell the linker to allocate no heap space via a passed in define (or just modify the linker script)-

-Wl,--defsym=__heap_size__=0

If you use newlib printf, then malloc_r will be hauled in even if not actually used for printf (you are not using stdio buffer). If malloc_r is hauled in, then you will need _sbrk(), and depending on which specs file is in use (nano/nosys/etc) it may or may not have _sbrk (nano does not). Then there is the symbol 'end' which newlib _sbrk uses as the start of heap (same as _sheap which is in your linker script, but most likely will need to add this 'end' symbol by duplicating the _sheap line in the linker script with the addition symbol name).

So, with __heap_size__ set to 0, and specs set to something other than nano, and 'end' is in the linker script- even if malloc attempts to use the heap it will fail because the .heap section size is 0 (_sbrk will always return -1). The malloc failure will be at runtime, but if it was used without your knowledge (library code) it will fail and the most probable outcome is something (you just added) will not work.

If using nano specs, then as soon as malloc_r is hauled in (because of some library function that needs it), you will get a linker error because the nano library has no _sbrk() function. You will know the code you  just added uses malloc.

If you want to use nano specs (libnano), and want to use printf, you can simply add your own _sbrk function-

extern "C" char* _sbrk(int n){ return (char*)-1; } //assumes in a C++ source file, so extern "C"

which simply causes a malloc_r failure. You can also do something else inside, and deal with it like an exception. For printf (typical uses), malloc does not actually allocate so _sbrk is never called but still has to be available (just as printf requires malloc_r to be available, even if not used).

an example makefile I use for stm32-
https://godbolt.org/z/T1oW3f4eE
In this case I have a wrap on malloc_r, although when using nano specs the missing _sbrk will cause an error anyway.