[PIC32CX-SG] built in buck converter and clock system. - Page 1
Forum section: electronics / general

author: Simon
author_rank: Unknown
timestamp: July 21, 2025, 07:59:43 am
content: I've just got myself the PIC32CX SG41 curiosity board and I am starting to write my setup code. The only way to run this at it's rated 120MHz is to use a PLL output of which there are 2 that can reach 200MHz and one that seems to have replaced the 48MHz RC oscillator in older parts as it only outputs 48MHz.I'm a little confused about how the 48MHz PLL works, it seems to use it's own output as the input? Which I need to switch away to the RTC crystal to make accurate.The 2 PLL's that can reach 200MHz say that to use then the power system must be in linear regulator mode. The chip seems to have a built in buck controller and the dev board does have the inductor on it. So I suppose I now have to pull that inductor off the board and jumper it's pads.Is this really necessary? I'm assuming the requirement is due to noise in the power supply affecting the PLL's functioning.

author: JPortici
author_rank: Super Contributor
timestamp: July 21, 2025, 08:46:05 am
content: These newerATSAMPIC32C parts are really weird. (i'm developing with the BZ series at the moment, it's a bloodbath but it's the only western part with radio connectivity at the moment that has an almost "sane" development environment.)Well, i always found ATSAM to have weird design choices (PICs were always more straightforward IMHO) it's almost like you need to use their vomit inducing code generatorsThe 48MHz PLL is a FRC, that can be phase locked to another clock source (derived from peripheral clock so - hopefully - from the other PLL, or oscillator) or from USB, so i think to make crystal-less USB 2.0? (see 18.2 in the datasheet)But from the clock diagram it seems you can't use the 48MHz internal clock to run the 200MHz PLL, so to achieve full speed you need an external source? bah. Even weirder than the PLL multiplying the 32KHz into the 200+ MHz rangeUnless the "GCLK_DPLLn" input can be taken from the 48MHz output -> Generic clock -> generic clock output... Weird, weird, weird. (Yes, confirmed in 18.6.5)Anyway: maybe the device needs to be in linear regulator mode because the buck converter interferes with the PLL?Also, 18.6.4 says: The DFLL48M can only be used with LDO regulator.

author: Simon
author_rank: Unknown
timestamp: July 21, 2025, 09:55:35 am
content: I have just been looking at some sample code I managed to download.Yes the DPLL0/1 can be run off the DFLL (what is the difference between DPLL and DFLL ?) providing the input is no more than 3 MHz so the 48 MHz output needs dividing by a generator first and then it can be multiplied to 120 MHz. What they do in the sample code is divide the 48 MHz to 1MHz and then use a 120 multiplier.What is confusing me is the closed loop for the DFLL48 or at least making it more accurate than the +/-15% 32 kHz ULP oscillator. I assume that to be accurate this needs to use the RTC crystal so I select this in the peripheral control channel.I won't use any code configurator. you have to understand the chips hardware anyway so read the datasheet, then you have to figure "the system" out. I have just started using C++ so that I can manage the code with classes, it's a very convenient way of working and I rather do that than do this massive setup that is stored in a file that will be useless if I have to change IDE.

author: JPortici
author_rank: Super Contributor
timestamp: July 21, 2025, 10:13:19 am
content: Quote from: Simon on July 21, 2025, 09:55:35 amI agree. And normally i would NEVER use code generators.But the wireless chips require a couple of library blobs that expect the pile of crap to be present. Well, at least freeRTOS, with a dedicated thread and set of queues of objects defined in the pile of crap.Believe me i tried my best to create a project from scratch that just included the blobs, header files, and freertos. But at some point I can't even get it to compile because there are some cross-include issues (A requires B which requires A) they fix with a convoluted inclusion mechanism. At some point i gave up and took a sample project i'm stripping away all of the crap i can.Creating a project from scratch from the crap configurator doesn't work on my machine.Still beats all the other manufacturers i evaluated. ESP32 can't be used because all the peripherals are utter shit, only good for the most basic of needs (i literally have a project right now with an H2 in which i'm bitbanging most peripherals.) and the analog part is.. you know..And the others have build chains that are bottomless pits of despair. Seriously, their examples don't compile, and trying to figure out zephir or how to change something in the provided configuration is too much.

author: Simon
author_rank: Unknown
timestamp: July 21, 2025, 11:38:44 am
content: Yes I decided to give the ESP32 a wide berth. A past colleague loves them but I wanted to see the datasheet and went right to the ADC and showed him how shit it is. Yes I know that some stuff is so complicated you do get trapped. Happily I am nowhere near that at the moment.I have the chip working on a 120MHz clock despite the buck converter. what baffles me is why microchip made a dev board with the buck converter only. All it needs is a pad to bridge the inductor and it's in LDO mode. Of course the first thing everyone wants to do is run at 120 MHz and you have to officially mod the board for that.

author: JPortici
author_rank: Super Contributor
timestamp: July 21, 2025, 12:11:24 pm
content: hmm.. i skimmed through the documentation and didn't see anything that indicated that you would need to remove the inductor.. After all it's a buck converter, i think in LDO mode they just keep the switch open so no current should be flowing between VSW and VDDCORE

author: Simon
author_rank: Unknown
timestamp: July 21, 2025, 12:17:11 pm
content: Section 58.2.2 of the datasheet, sorry the inductor pad would not be bridged, it would be left open. They could of had a 0 ohm resistor in series that could have been placed if the user wanted the buck

author: ataradov
author_rank: Super Contributor
timestamp: July 21, 2025, 01:59:13 pm
content: PIC32CX SG41 is the same device as SAM E51/D51. And you will have way more luck locating code for those.The inductor may be left, it does not matter in linear mode. VSW pin is high impedance in linear mode anyway. The reason you don't want buck mode with PLLs is that it generates a ton of internal noise, affecting the PLLs.Here is example for SAM D51 that initialized DPLL0 for 120 MHz using 32 kHz oscillator as a referencehttps://github.com/ataradov/mcu-starter-projects/blob/master/samd51/main.c.

author: Simon
author_rank: Unknown
timestamp: July 21, 2025, 03:15:03 pm
content: Ah thanks, would the SAM E51/D51 by any chance in turn be a development of the SAMC? I see many similarities in the SAMC and PIC32CX-SG. I was speculating that the "C" was a reference to the SAMC but I expect that a lot of the peripherals are reused on other chips. My TCC code looks like it will be identical with pretty much no changes in the registers.So does the ratio of the PLL affect it's vulnerability? I've got a 12 MHz oscillator on the dev board so it's a 128 multiplication as the example code I found was feeding 48 MHz/48 to the PLL so I just made it the same. But the PLL can work with up to 3.2MHz input so I could divide it by 4 and then multiply by 40 rather than 120.One thing I noticed was that the generic clock generator registers in the datasheet may have an error. Apparently division of the clock source is possible by up to 512 but they are 8 bit registers. I was speculating that maybe enabling the division did the first /2 with 256 subsequent ratios available but I think it's just a typo.

author: ataradov
author_rank: Super Contributor
timestamp: July 21, 2025, 04:19:12 pm
content: Well, they are all based on the same basic peripheral set, but this is common among all vendors. You don't make new peripherals for each new MCU unless there is a good reason. Otherwise, C21 and D51/E51 are pretty different devices.PIC32CX SG41 and SAM D51/E51 are literally the same device.No, ratio does not matter, the noise affects the control voltage of the VCO, so it will be the same for any multiplication factor. You simply can't use PLL and Buck regulator at the same time. You may get lucky and it might work in your design, but generally you should not do that.Division factors are different depending on the index. Most of them are 8 bits in size, the only one that is 16 bits is Generator 1. But actual division can be much higher if you use DIVSEL bit.

author: Simon
author_rank: Unknown
timestamp: July 21, 2025, 05:17:46 pm
content: Ah yes I remember now. The way they wrote the explanation I was starting to think that it enabled the division which is silly of course. I'll update my code tomorrow for the 2^N divisions.I'll have to pop that inductor off tomorrow.

author: ataradov
author_rank: Super Contributor
timestamp: July 21, 2025, 06:21:59 pm
content: Why? Inductor can stay. It does not do anything if you don't use Buck mode.

author: Simon
author_rank: Unknown
timestamp: July 21, 2025, 06:40:44 pm
content: How do I stop it from using buck mode? I looked through the datasheet and from what I could tell it said that if there is an inductor it's in buck mode, if it is not there it is in LDO mode.

author: ataradov
author_rank: Super Contributor
timestamp: July 21, 2025, 06:52:04 pm
content: You have to actively enable buck mode using SUPC->VREG->SEL, by default it is in.LDO mode. It does not know if there is inductor or not.

author: Simon
author_rank: Unknown
timestamp: July 21, 2025, 07:04:26 pm
content: Ah, OK, thank you.

author: Simon
author_rank: Unknown
timestamp: July 22, 2025, 10:32:59 am
content: Well there are some things about the GCLK that are not explained or are a bug. I wrote a generator setup functionCode:static void gclk_gen_setup(unsigned gen_n, clk_gen_src_t src, uint16_t div, bool out_en){if (div > 1) {uint32_t idc = 0;if (div % 2) idc = 1;GCLK_REGS->GCLK_GENCTRL = GCLK_GENCTRL_DIV(div) | GCLK_GENCTRL_OE(out_en) | GCLK_GENCTRL_IDC(idc) | GCLK_GENCTRL_GENEN_Msk | GCLK_GENCTRL_SRC(src);} else GCLK_REGS->GCLK_GENCTRL = GCLK_GENCTRL_DIV(1) | GCLK_GENCTRL_OE(out_en) | GCLK_GENCTRL_GENEN_Msk | GCLK_GENCTRL_SRC(src);while ((GCLK_REGS->GCLK_SYNCBUSY & (0x4 << gen_n)) == (0x4 << gen_n)) {}return;}Initially I did not have GCLK_GENCTRL_DIV(1) in the else line. It worked fine with generator 0 but the program would baulk to the dummy handler when I used it on generator 2. But according to the datasheet if I don't want to divide the clock I can set the DIV register bits to 1 or 0. Well it was not until I set it to 1 that it worked.When DIVSEL is 1 the division factor is 2^(DIV+1) so even with a 0 there will be a one. But the datasheet says that to not divide the close DIVSEL must be 0 and DIV may be 0 or 1. This is wrong on generators that are not 0. the clock calculation must not have a DIV of 0 or it fails. 0 can probably only be used when DIVSEL is 1 ans 1 is added to DIV anyway.

author: ataradov
author_rank: Super Contributor
timestamp: July 22, 2025, 01:46:12 pm
content: Nothing can g into a dummy handler because of the bad clock configuration. GCLK can't do that. The only time it might happen is when the user of the clock does something bad. It is hard to tell without looking into the details.I don't think there are any bugs here, something else is going on in your case. You can always test this by putting the clock on the pin and checking how it behaves regardless of what the rest of the system is doing.Also, you can use DIVSEL=1 and DIV=0 to get division by one. The datasheet just provided one example of how to get one.

author: Simon
author_rank: Unknown
timestamp: July 22, 2025, 04:52:01 pm
content: Yes, that is what I am thinking too. Once I stopped using that function and just did a register assignment it worked. It's all very confusing.What I was suspecting was that if you look at the result of the calculation.DIVSEL DIV RESULT0 0 00 1 11 0 11 1 2So only the first case produces an actual divider result of 0. I don't know if the hardware sets it to 1 anyway.

author: Simon
author_rank: Unknown
timestamp: July 22, 2025, 05:21:57 pm
content: What I am quite confused about is what to put for the while loop when waiting for a flag in a register.while(condition)while(condition){}while(condition) ;while(condition){;}I think I'll also try using the PICKIT5, I keep getting spurious failures that resolve themselves after unplugging the dev board and plugging it back in again. Or by doing a straight program of the board and then a debug session.

author: ataradov
author_rank: Super Contributor
timestamp: July 22, 2025, 06:39:21 pm
content: Zero configured divider would result in no division (division by 1).The fist while is incorrect, since it will execute the next statement as a body. The last 3 are identical.

author: Simon
author_rank: Unknown
timestamp: July 22, 2025, 06:51:47 pm
content: Right so with the braces I suppose it's clear that the code to run is in there and it's nothing. But the semicolon? presumably that is an empty statement but like an if statement that has only one statement it does not need braces to denote a code block.

author: ataradov
author_rank: Super Contributor
timestamp: July 22, 2025, 07:12:39 pm
content: Well, it is a matter of style. I personally do "while (condition);" .

author: Simon
author_rank: Unknown
timestamp: July 22, 2025, 07:36:06 pm
content: Yea, that is my prefered way. MPLABX at least the way I have it setup will insist on putting The closing brace on a new line so the colon method is the most compact.

author: Simon
author_rank: Unknown
timestamp: July 24, 2025, 08:42:38 am
content: Should I have the "use software breakpoints" enabled on the pickit5? Seems to not like it.

author: ataradov
author_rank: Super Contributor
timestamp: July 24, 2025, 01:42:10 pm
content: It depends. I personally would never do it, as it is potentially more intrusive than regular debugging already is. But some people like to have a ton of breakpoints active at the sane time and then you don't have a choice.

author: Simon
author_rank: Unknown
timestamp: July 24, 2025, 04:03:42 pm
content: Oh I see. I am just trying to work out the most stable way of running so that when there is a problem, I know it's me and not this steaming pile of you know what. The datasheet is riddled with errors, omissions or smacks of being written by someone who does not know English to a sufficient degree. The SAMC datasheet was much better.The clock generator output pins description was probably lifted from another chip (SAMC?) with 9 generators rather than 12. It says that generators 0-7 have IO pins and 8 does not, it does not bother to mention generators 9, 10 &11. These also did do not have outputs from what the multiplexing table shows. No big deal, but sloppy.NVMC Table 9-5 has an error:35:25 Reserved36:32 USB TRANSNThe reserved can't be up to 35 and then the USB goes back to 32. I take it that the reserved is 5 bits, it follows the adc1 settings and the reserved bits after adc0 is 5 bits so I guess it is the same pattern.

author: ataradov
author_rank: Super Contributor
timestamp: July 24, 2025, 04:15:17 pm
content: I'm pretty sure it was written by mostly the same people. They are compiled from chapters written for a generic peripheral with minor corrections for the specific implementation.Preparing those documents is a ton of work, so I'm not surprised that errors happen. Those are usually fixed in the next revision when reported.

author: Simon
author_rank: Unknown
timestamp: July 24, 2025, 07:14:56 pm
content: Yea I know.

author: Simon
author_rank: Unknown
timestamp: July 25, 2025, 11:26:51 am
content: with the dev boards onboard debugger (pickit4?) I often get the following error when I do a debug program: Failed while checking for software breakpoints. The current PC, fffffffe, is not within any known instruction memory.Usually doing a plain write the program to the board and then debug program fixes it as does unplugging it and plugging it in again. Is this just one of those things? I saw a thread that was quite old where a guy claimed he had to unplug and plug in his pickit4 between programming.

author: ataradov
author_rank: Super Contributor
timestamp: July 25, 2025, 02:06:26 pm
content: No idea, all Microchip software is pure crap, I have not used it enough to know all the issues.

author: Simon
author_rank: Unknown
timestamp: July 25, 2025, 02:52:16 pm
content: Is there any other IDE I can use, MPLAB.X is definitely not a patch on studio but they won't add compatibility to studio for the newer chips or tools.

author: ataradov
author_rank: Super Contributor
timestamp: July 25, 2025, 03:12:41 pm
content: No idea, I don't use IDEs. I think a common thing to use is VS Code, and I think even Microchip would be migrating to that. I think you can set it up independently, but I have not done it myself.

author: Simon
author_rank: Unknown
timestamp: July 26, 2025, 08:16:55 am
content: Yes I have seen the VSC plugin. But are the problems coming from netbeans or the mplabx stuff? The VSC plugin is called mplabx too. I assume that as much of what was already in existence has been reused and the debugger communication and handling is very much microchip specific.

author: ataradov
author_rank: Super Contributor
timestamp: July 26, 2025, 01:42:45 pm
content: You don't have to use any of the Microchip stuff. You can build the whole dev chain from fully open components with some effort.But also, they will slap MPLAB on anything, just like they like to slap PIC on anything they touch. I would not just infer that there is any commonality.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 26, 2025, 03:23:25 pm
content: Yes, the PIC32C series is ARM-based (the CX-SG is Cortex-M4F), so any ARM Cortex M toolchain will work. Now, as always, unless you want to re-create all support files from scratch, you have to find a way to extract them and so you probablly need to install something from Microchip first. Don't know what the minimal "package" would be, it's such a mess. They don't seem to be distributing anything outside of MPLAB anymore, so I guess you still have to install it, keep the support files and remove the rest.

author: Simon
author_rank: Unknown
timestamp: July 26, 2025, 03:59:52 pm
content: what do you mean by support files? The device headers are easy to locate and there are also files in the "pack" that set the processor options.The other bit is how do I get a debugger to work? I don't know if the pickit5 has some sort of standard interfacing protocol that "just" need a driver.

author: ataradov
author_rank: Super Contributor
timestamp: July 26, 2025, 08:03:49 pm
content: All you really need are device pack and those are available as standalone archives herehttps://packs.download.microchip.com/With open tools you will need whatever debugger is supported by OpenOCD.All the driver code is inn Harmony. And if you want to use it (as in generate final code), then you will need to have code generator installed. But if you just want it for a reference, then you can browse it right on GitHub.

author: Simon
author_rank: Unknown
timestamp: July 27, 2025, 07:25:42 am
content: So how universal is OpenOCD ?

author: Simon
author_rank: Unknown
timestamp: July 27, 2025, 07:47:30 am
content: What exactly is your setup?

author: ataradov
author_rank: Super Contributor
timestamp: July 27, 2025, 02:44:04 pm
content: Quote from: Simon on July 27, 2025, 07:25:42 amIt is more universal that any single vendor tools.Quote from: Simon on July 27, 2025, 07:47:30 amSimple text editor, Makefile, edbg for programming (https://github.com/ataradov/edbg). I don't do stepping debugging, so I don't have a need for a debugger.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 27, 2025, 02:46:11 pm
content: Quote from: ataradov on July 26, 2025, 08:03:49 pmOk, great, that's the one thing I wasn't sure existed. Too bad they don't seem to put an obvious link to the right package on the product pages, but I may have missed it!

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 27, 2025, 02:52:38 pm
content: Quote from: Simon on July 27, 2025, 07:25:42 amSo, with OpenOCD you can use just any supported probe. I suppose Microchip Cortex-M MCUs have a SWD interface, so all you need is a SWD probe. There are tons of such probes available for cheap (or less cheap), you don't need Microchip tools, which becomes great. So you can use FTDI-based debug probes, or DAP ones, for instance. Or even a STLINK interface, if you happen to have one.OpenOCD has a GDB server. So all you need to "step debug", apart from OpenOCD, is GDB, which ships with all GCC-based toolchains.You can use GDB both to flash the MCU and to step-debug it. It can be used as a CLI tool with a terminal interface. There are also a bunch of "IDEs"/programming editors that have an extension that provide a GUI front-end to GDB if you want that. If you use VS Code, there's a specific extension:https://marketplace.visualstudio.com/items?itemName=onethinx.cortex-gdb

author: Simon
author_rank: Unknown
timestamp: July 29, 2025, 08:09:20 am
content: A long time ago we talked about the CAN ram memory allocation. The CAN controllers (Bosch MTTCAN) can address a little over 16 kB of memory. The CAN controllers have registers to store the addresses of the buffers in RAM. These are 16 bit so they can address up to 64 kB. On the SAMC the ram was no more than 32 kB so I could simply create a variable of my own can_ram_type and put the address of the variuos buffers into the CAN controller config registers.Now I have 256 kB of RAM. I also see that thee is a define in the chips header files:#define CAN0_MSG_RAM_ADDR (0x20000000)That is the start of the RAM space. I take it therefore that it is not a case of allocating the CAN RAM space to a memory location that does not cross a 16 or 64 kB boundary but actually making sure that it is physically allocated below the 64 kB limit. So rather than my code configure the CAN controller with the address of the declared RAM variable I need to work with a pointer to an address of can_ram_type so that I have physically specified it correctly.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 29, 2025, 12:40:43 pm
content: Regarding OpenOCD, I'll have to unfortunately curb the enthusiasm: it doesn't seem to support the PIC32C series as of yet. The only PIC32 support I found is for the MX.

author: JPortici
author_rank: Super Contributor
timestamp: July 29, 2025, 01:22:57 pm
content: Quote from: SiliconWizard on July 29, 2025, 12:40:43 pmThey are literally renamed ATSAM devices, for some retarded marketing reason (they really want to have something mainstream branded as PIC32. They have renamed ATSAM into PIC32C, they have renamed dsPIC33A to PIC32A but keep the product separated and with two supposedly identical toolchains. Retarded because they haven't renamed AVR into PIC18A or something stupid like that - yet)

author: Simon
author_rank: Unknown
timestamp: July 29, 2025, 02:56:22 pm
content: No they instead rearranged the AVR names. It seems that Mr D. Head that was in charge of the pickit 3 development is also the one in charge of naming things.They rebranded the ATXMega's as ATMega's, oh, hangon they also rebranded the ATXMega's to tiny too. Basically dropped the Xmega name but kept the architecture. So they used the other 2 very well established names to describe the also established line up whose name had been dropped.I suspect that people stopped using them because they go fed up with googling for information about one chip to find themselves faced with a sea of "legacy" information about a chip with the same name that was totally different.Microchip sadly joins many other huge companies like Microsoft and Google who are so huge that they cannot fail no matter how hard their developers and product managers try to crash the company by pissing people off who have nowhere else to go.

author: Simon
author_rank: Unknown
timestamp: August 06, 2025, 04:02:38 pm
content: OK, so now I do have "the" problem. Creating a structured type for the CAN RAM area and creating pointers to it does not allocate this RAM space to the can bus.I was just trying to work out why one of the busses works very slowly and it turns out that the baud rate variable in my class is being overwritten by something. Which is no surprise as it resides at address 0x20000000, the start of the RAM area, and not by chance the very same address that I chose to point my CAN0 RAM data structure at. No wonder everything is falling on it's ass at random.So How do I do this? The CAN controller can only address 64 kB of RAM and the RAM available is 256 kB. I assume that the compiler is not aware of the addressing needs of the CAN controllers and will not guarantee to place variables I declare under the 64 kB limit?Is there a way to define a variable and set it's exact location start?

author: ataradov
author_rank: Super Contributor
timestamp: August 06, 2025, 04:08:13 pm
content: For XC32 there is some argument that lets you place a variable at a fixed address. Read the manual for the compiler, I don't remember the exact syntax.For GCC, place this variable in a section and collect that section first in the linker script.

author: Simon
author_rank: Unknown
timestamp: August 07, 2025, 08:09:01 am
content: Yep, page 114,__attribute__((address(0x20000000)))Annoyingly the ARM compiler uses __attribute__((at(0x20000000))), at this rate I will be using another IDE.

author: ataradov
author_rank: Super Contributor
timestamp: August 07, 2025, 01:45:35 pm
content: I personally would not use XC32. it has some nice things like this, but they are impended in a hacked way and you loose fine control over the rests of the linker functionality.

author: Simon
author_rank: Unknown
timestamp: August 07, 2025, 03:27:04 pm
content: OK, thing is I am really confused as to what ARM compiler I should use. The ARM website is a bit of a maze and one simply cannot "just" download the cortex-M compiler without some sort of kung-foo that so far illumes me.I had at one point a compiler that was at version 14 but these days the numbers are around 6, maybe because they bought Keil and has the Keil compiler become the ARM one?My last attempt at downloading the compiler resulted in something that was not what I needed.

author: ataradov
author_rank: Super Contributor
timestamp: August 07, 2025, 03:31:30 pm
content: I don't understand the confusion. Just googling "ARM compiler" head me to this pagehttps://developer.arm.com/downloads/-/arm-gnu-toolchain-downloadsPick the one for your OS type and download that.14 is likely GCC, 6 is Keil. Keil is a commercial product, and it is the IDE, the actual compiler in the v6 is Clang. ARM provides builds of GCC for free and you obviously have to pay for Keil.

author: Simon
author_rank: Unknown
timestamp: August 07, 2025, 04:19:39 pm
content: Well there is this problem we have, Studio is being forced out because why keep stuff that works, people don't buy things from companies they like. MPLAB.X is some sort of malformed thing that rather than being drowned at birth has been allowed to life and scare the pants off anyone that tries to interact with it.Both options have issues with out server (or our server is run by people that have to complicate matters) so I am considering another IDE. I don't much like the idea of VSC, that feels like a cop out bit µVision looks a bit dated. Still if it works and is solid.Problem is most IDE's need admin rights and our server does not have mapped drives for admins.

author: ataradov
author_rank: Super Contributor
timestamp: August 07, 2025, 04:34:41 pm
content: It all depends on the type of workflow you like. I personally would not use IDEs. Just use the text editor you like with makefiles to build. And standalone debugger for debugging. Segger Ozone is a really good debugger.This gives you way more options. Instead of picking a single IDE trying to balance disadvantages, you get to pick the best editor and then the best debugger. And if the editor you picked does not work anymore or something better comes along, you can just switch the editor without affecting the debug flow at all.

author: Simon
author_rank: Unknown
timestamp: August 08, 2025, 09:26:53 am
content: What exactly do you mean by text editor? something as simple as notepad, or are we talking nodepad++ that I have not used but am aware is useful for programming.So I would need to write my own make file (I only know what it does not how it works).compile from the command line?Use a stand alone debugger program and compatible hardware to connect to the micro controller and see what is going on.Ah, any segger debugger is a minimum of 1400 of anyone's currency

author: Simon
author_rank: Unknown
timestamp: August 08, 2025, 10:45:50 am
content: Quote from: ataradov on August 07, 2025, 03:31:30 pmOK, next hurdle, this time not the IDE, ARM GNU compiler does not support __attribute__((at(address))) so now I am forced to use microchips or Keil, this is kind of the thing. There are more things than compilers and other software so I don't think there is a ever a totally free choice.I'll try and find the arm-gnu++ compiler manual. At some point I need to generate some work....

author: ataradov
author_rank: Super Contributor
timestamp: August 08, 2025, 03:37:21 pm
content: Quote from: Simon on August 08, 2025, 09:26:53 amAny one you like. I often use SublimeText, but I'm not too attached to it. I just use whatever is available. Probably not a Notepad though.Quote from: Simon on August 08, 2025, 09:26:53 amYes, it is not that hard, and you generally just need to do it once.Quote from: Simon on August 08, 2025, 09:26:53 amEither run 'make' from command line, or use a text editor that can run an action on hot key. Most editors more advanced than Notepad can do that.Quote from: Simon on August 08, 2025, 09:26:53 amGDB is free and works with cheap hardware. It all depends on the value of your time and your debugging style. Note, I don't own any J-Link hardware, but I also don't use debuggers in general.

author: ataradov
author_rank: Super Contributor
timestamp: August 08, 2025, 03:38:46 pm
content: Quote from: Simon on August 08, 2025, 10:45:50 amNo, you are not. Place that variable into a section and place that section at the beginning of SRAM in the linker script.

author: Simon
author_rank: Unknown
timestamp: August 08, 2025, 04:59:26 pm
content: Quote from: ataradov on August 08, 2025, 03:38:46 pmYes, I'll have to find out how to do that.And by text editor you mean something like VSC.Yes my time is quite precious, as it is I do not have the time to do the work.

author: ataradov
author_rank: Super Contributor
timestamp: August 08, 2025, 05:19:39 pm
content: In the code:Code:__attribute__ ((section(".can_ram"))) uint8_t can_buffer[...];The linker script part depends on how your linker script is organized. Part that deals with SRAM might looks something like this:Code:.data : ALIGN(4){FILL(0xff)_data = .;*(.can_ram); // Adding this line will place can_buffer into the initialized data section. This will guarantee that it goes first in the SRAM, but it will also eat the flash because it is initialized.*(.ramfunc .ramfunc.*);*(vtable)*(.data*). = ALIGN(4);_edata = .;} > ram AT > flash.bss : ALIGN(4){_bss = .;*(.can_ram); // Adding this line will place can_buffer into the uninitialized data section. It will go after all the initialized variables, but will not take any space in the flash.*(.bss*)*(COMMON). = ALIGN(4);_ebss = .;PROVIDE(_end = .);} > ramAssuming you don't have 64 K of initialized variables, the second one is probably better.Another option is to edit MEMORY {...} section and just adjust the RAM start and size to fit your buffer. This way compiler will not use the RAM at the beginning and you can use it for the buffer.

author: Simon
author_rank: Unknown
timestamp: August 09, 2025, 10:08:45 am
content: So in an mplabx project where would I expect to find the linker script? or is this a file that is in the tool chain?Where is "MEMORY {...}"The chip header file has an address for the start of the RAM so I could meddle with that and then use pointers of type can_ram on the lower end of the RAM space with the compiler using anything above my edited address.There are 3 types of RAM set to the RAM base address:#define HSRAM_ADDR _UINT32_(0x20000000) /* HSRAM base address (type: ram)*/#define HSRAM_ETB_ADDR _UINT32_(0x20000000) /* HSRAM_ETB base address (type: ram)*/#define HSRAM_RET1_ADDR _UINT32_(0x20000000) /* HSRAM_RET1 base address (type: ram)*/So I know that HSRAM is "the RAM" the other two I don't know if they would move with it or if they are something else that needs to know where the physical RAM starts.

author: ataradov
author_rank: Super Contributor
timestamp: August 09, 2025, 02:49:25 pm
content: Similar to this pathhttps://github.com/Microchip-MPLAB-Harmony/csp_apps_pic32cx_sg41/blob/master/apps/port/port_led_on_off_polling/firmware/src/config/pic32cx_sg41_cult/PIC32CX1025SG41128.ldBut XC32 linker scripts are slightly different because they modified their linker to support that at() attribute. There is no explicit data section. If you are going to stay with XC32, then use that. If you are going to move away from it, you will need to make a new linker script or edit the existing one.

author: Simon
author_rank: Unknown
timestamp: August 11, 2025, 07:31:26 am
content: Well I installed the ARM GNU compiler and recompiled with it and was hoping to find a script file to get me going.

author: Simon
author_rank: Unknown
timestamp: August 11, 2025, 10:05:33 am
content: I see, the linker script is in the device pack not the project

author: ataradov
author_rank: Super Contributor
timestamp: August 11, 2025, 01:49:12 pm
content: The linker script is part of the project. It is copied from the device pack to the path similar to what I shown. You can always find the location of it by looking in the build logs. The linker will take it as a parameter.

author: Simon
author_rank: Unknown
timestamp: August 11, 2025, 03:00:10 pm
content: Yes MPLAB.x is linking to the device_name.id file in the device pack:Info: Loading file: ./C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140/xc32/PIC32CX1025SG41128/PIC32CX1025SG41128.ldTotal output belowCode:make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-confmake -f nbproject/Makefile-default.mk dist/default/debug/PIC32CX-SG.X.debug.elfmake: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -D__DEBUG -x c++ -c -mprocessor=32CX1025SG41128 -frtti -fexceptions -fno-check-new -fenforce-eh-specs -I"../PIC32CX-SG_CPP" -I"hw_settings" -MMD -MF "build/default/debug/main.o.d" -o build/default/debug/main.o main.cpp -DXPRJ_default=default -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140" -I "C:/Users/sturner/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'make: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -D__DEBUG -x c++ -c -mprocessor=32CX1025SG41128 -frtti -fexceptions -fno-check-new -fenforce-eh-specs -I"../PIC32CX-SG_CPP" -I"hw_settings" -MMD -MF "build/default/debug/_ext/476711306/diagnostics.o.d" -o build/default/debug/_ext/476711306/diagnostics.o ../PIC32CX-SG_CPP/diagnostics.cpp -DXPRJ_default=default -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140" -I "C:/Users/sturner/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'make: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -D__DEBUG -x c++ -c -mprocessor=32CX1025SG41128 -frtti -fexceptions -fno-check-new -fenforce-eh-specs -I"../PIC32CX-SG_CPP" -I"hw_settings" -MMD -MF "build/default/debug/_ext/476711306/port_control.o.d" -o build/default/debug/_ext/476711306/port_control.o ../PIC32CX-SG_CPP/port_control.cpp -DXPRJ_default=default -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140" -I "C:/Users/sturner/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'make: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -D__DEBUG -x c++ -c -mprocessor=32CX1025SG41128 -frtti -fexceptions -fno-check-new -fenforce-eh-specs -I"../PIC32CX-SG_CPP" -I"hw_settings" -MMD -MF "build/default/debug/_ext/476711306/clock.o.d" -o build/default/debug/_ext/476711306/clock.o ../PIC32CX-SG_CPP/clock.cpp -DXPRJ_default=default -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140" -I "C:/Users/sturner/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'make: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -D__DEBUG -x c++ -c -mprocessor=32CX1025SG41128 -frtti -fexceptions -fno-check-new -fenforce-eh-specs -I"../PIC32CX-SG_CPP" -I"hw_settings" -MMD -MF "build/default/debug/_ext/476711306/class_gpio.o.d" -o build/default/debug/_ext/476711306/class_gpio.o ../PIC32CX-SG_CPP/class_gpio.cpp -DXPRJ_default=default -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140" -I "C:/Users/sturner/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'make: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -D__DEBUG -x c++ -c -mprocessor=32CX1025SG41128 -frtti -fexceptions -fno-check-new -fenforce-eh-specs -I"../PIC32CX-SG_CPP" -I"hw_settings" -MMD -MF "build/default/debug/_ext/476711306/can_open_comms_dictionary.o.d" -o build/default/debug/_ext/476711306/can_open_comms_dictionary.o ../PIC32CX-SG_CPP/can_open_comms_dictionary.cpp -DXPRJ_default=default -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140" -I "C:/Users/sturner/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'make: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -D__DEBUG -x c++ -c -mprocessor=32CX1025SG41128 -frtti -fexceptions -fno-check-new -fenforce-eh-specs -I"../PIC32CX-SG_CPP" -I"hw_settings" -MMD -MF "build/default/debug/_ext/476711306/class_tcc.o.d" -o build/default/debug/_ext/476711306/class_tcc.o ../PIC32CX-SG_CPP/class_tcc.cpp -DXPRJ_default=default -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140" -I "C:/Users/sturner/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'make: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -D__DEBUG -x c++ -c -mprocessor=32CX1025SG41128 -frtti -fexceptions -fno-check-new -fenforce-eh-specs -I"../PIC32CX-SG_CPP" -I"hw_settings" -MMD -MF "build/default/debug/_ext/476711306/rtc.o.d" -o build/default/debug/_ext/476711306/rtc.o ../PIC32CX-SG_CPP/rtc.cpp -DXPRJ_default=default -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140" -I "C:/Users/sturner/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'make: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -D__DEBUG -x c++ -c -mprocessor=32CX1025SG41128 -frtti -fexceptions -fno-check-new -fenforce-eh-specs -I"../PIC32CX-SG_CPP" -I"hw_settings" -MMD -MF "build/default/debug/_ext/476711306/class_adc.o.d" -o build/default/debug/_ext/476711306/class_adc.o ../PIC32CX-SG_CPP/class_adc.cpp -DXPRJ_default=default -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140" -I "C:/Users/sturner/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'make: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -D__DEBUG -x c++ -c -mprocessor=32CX1025SG41128 -frtti -fexceptions -fno-check-new -fenforce-eh-specs -I"../PIC32CX-SG_CPP" -I"hw_settings" -MMD -MF "build/default/debug/_ext/476711306/can_open_slave_class.o.d" -o build/default/debug/_ext/476711306/can_open_slave_class.o ../PIC32CX-SG_CPP/can_open_slave_class.cpp -DXPRJ_default=default -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140" -I "C:/Users/sturner/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'make: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -D__DEBUG -x c++ -c -mprocessor=32CX1025SG41128 -frtti -fexceptions -fno-check-new -fenforce-eh-specs -I"../PIC32CX-SG_CPP" -I"hw_settings" -MMD -MF "build/default/debug/_ext/476711306/can_open_class.o.d" -o build/default/debug/_ext/476711306/can_open_class.o ../PIC32CX-SG_CPP/can_open_class.cpp -DXPRJ_default=default -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140" -I "C:/Users/sturner/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'make: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -D__DEBUG -x c++ -c -mprocessor=32CX1025SG41128 -frtti -fexceptions -fno-check-new -fenforce-eh-specs -I"../PIC32CX-SG_CPP" -I"hw_settings" -MMD -MF "build/default/debug/_ext/476711306/can_open_master_class.o.d" -o build/default/debug/_ext/476711306/can_open_master_class.o ../PIC32CX-SG_CPP/can_open_master_class.cpp -DXPRJ_default=default -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140" -I "C:/Users/sturner/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'make: Entering directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'"C:\Program Files\Microchip\xc32\v4.60\bin\xc32-g++.exe" -g -mprocessor=32CX1025SG41128 -o dist/default/debug/PIC32CX-SG.X.debug.elf build/default/debug/main.o build/default/debug/_ext/476711306/clock.o build/default/debug/_ext/476711306/diagnostics.o build/default/debug/_ext/476711306/port_control.o build/default/debug/_ext/476711306/class_gpio.o build/default/debug/_ext/476711306/class_tcc.o build/default/debug/_ext/476711306/class_adc.o build/default/debug/_ext/476711306/rtc.o build/default/debug/_ext/476711306/can_open_comms_dictionary.o build/default/debug/_ext/476711306/can_open_class.o build/default/debug/_ext/476711306/can_open_slave_class.o build/default/debug/_ext/476711306/can_open_master_class.o -DXPRJ_default=default -Wl,--defsym=__MPLAB_BUILD=1,--defsym=__ICD2RAM=1,--defsym=__MPLAB_DEBUG=1,--defsym=__DEBUG=1,-D=__DEBUG_D,-Map="dist/default/debug/PIC32CX-SG.X.debug.map",--memorysummary,dist/default/debug/memoryfile.xml -mdfp="C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140"make: Leaving directory 'C:/One/OneDrive - /Project_Firmware/PIC32CX-SG.X'Info: Loading file: ./C:/Program Files/Microchip/MPLABX/v6.25/packs/Microchip/PIC32CX-SG41_DFP/1.5.140/xc32/PIC32CX1025SG41128/PIC32CX1025SG41128.ld

author: ataradov
author_rank: Super Contributor
timestamp: August 11, 2025, 03:09:22 pm
content: Was this a Harmony project? Or just a plain project? I'm guessing the later, since Harmony places all the files need to build the project.Linker file is an inherent part of the code, it is just as important as main.c. Anyone even considering making an IDE that just references pack files has no clue what they are doing. Your project gains dependency on the exact version of the pack. If you open that project later when the pack is updated, you have no reproducible build.I would make sure that linker file and all the dependencies are packaged as part of your project and version controlled along with the rest of the code.

author: Simon
author_rank: Unknown
timestamp: August 11, 2025, 03:56:00 pm
content: It's a plain project as you say. I did not alter any settings, this is how they do it by default I assume. As we all agree this particular IDE is an abomination, this is why I am trying to work this stuff out so that I can "move out".I think I am going to end up on VSC, I have hardly used it and it seems to be the minimum I will need unless I really am going command line. So I can use the ARM GNU compiler and I need to understand the linker file modifications required.The other part of this will be working out how/what to debug with, I have to do this gradually as time permits around the projects I am working on.The other problem I need to work out is file management. I have ended up on my one drive and this is not ideal as no one else can access my work.Studio had to be run in admin mode.I have defaulted to the same for MPLABX, I do not know if it is neccessary. Some internet searchs give results that advise it but don't say specifically why.The problem that admin mode brings is that I cannot access our server as mapped drives, the IT company have refused to take this any further. As things stand with MPLABX it seems to work but on opening there is a warning:Some of the files in this Project contain spaces or odd characters in their name or their path. This could potentially cause issues during the build process. This is a limitation of GNU Make tool that we use as part of our build process. Removing spaces from all file and folder names included in this project will eliminate this potential issue.Now it sounds like this will be a problem even for the ARM GNU compiler under whatever text editor. Is this actually a problem or just an over pedantic warning? Things seem to be working ok, I know there are spaces, I can't get the IT company to deal with that, I don't know what an "odd" character is but I use no spaces and normal chars in all my file/folder names. I already had to make them move my one drive location to reduce the path length.Will VSC and the ARM GNU toolchain still have these issues? Basically my boss wants to find a solution to this with the IT company, so unless I can run VSC without admin I will probably still have an issue with path lengths and characters which will have to be sorted out with the IT supplier.

author: ataradov
author_rank: Super Contributor
timestamp: August 11, 2025, 04:26:18 pm
content: I never hard to run Studio in admin mode. I would look into resolving any issues that require admin mode, it should not be necessary.I would not use spaces in paths. It may work and possible to make it work, but it is just asking for extra issues. You will have to figure out how to quote strings with spaces for various tools. If you really want it, you will just have to figure that out and apply that quoting everywhere. By default make uses spaces as entity separators, so simply using paths with spaces will not work.

author: Simon
author_rank: Unknown
timestamp: August 11, 2025, 07:21:59 pm
content: Well in both companies I have worked random issues occurred with studio, always solved by running it with admin rights. I don't know the details of how windows accounts and their permissions work and how many variants there are on things that can be controlled. Last time the issue was that I could not program as the IDE could not run the USB link, admin rights fixed it. I can't fix these problems and the IT company don't have a clue about programming IDE's and really they could not give a shit!So by default I started using MPLABX as an admin too because when weird shit happens I don't know if it is the shitty IDE, the shitty programmer/debugger/dev board something I have done or some shitty mess that windows under the command and control of the shitty IT company is doing. So I play it safe.I can't not have spaces in the file paths because someone else has set everything else up. When I got them to move the one drive location because I can't even manage that for myself I asked them to change it's name to no have spaces and they refused. It's something to do with how it's set up and how their company works.So now I have scared my boss by going on holiday for 3 days and not programming that urgent board, he is very interested in having things sorted out now. Unfortunately whimsical warning messages that turn out to be empty threats are not very encouraging when I have to tell someone they may have to spend a load of money because I say so.I mean basically am I best with a non domained machine and a NAS box ?

author: ataradov
author_rank: Super Contributor
timestamp: August 11, 2025, 09:40:23 pm
content: Those are real warning messages. It is not make or GCC issue either, it is just a common thing with how parameters are passed to the command line programs.ThisCode:gcc "main with spaces.c"will compile fine.ThisCode:gcc main with spaces.cwill obviously fail.This is all that warning is telling you. I'm sure IDE will do its best to quote all the files, but it might miss some corner case.And if you are writing Makefiles yourself, you will have to do this quoting.

author: Simon
author_rank: Unknown
timestamp: August 12, 2025, 01:55:32 pm
content: Right so if I am not using an IDE I definitely need to avoid spaces as this is a tool chain thing and the MPLAB IDE is trying to hold my hand or at least that of our IT supplier. I don't have any strange stuff that I am aware of and so far no issues.So first thing I expect is to sort out a debugging system and see if I can piece it all together.

author: ataradov
author_rank: Super Contributor
timestamp: August 12, 2025, 02:02:21 pm
content: You don't have to avoid spaces, you just have to write your makefiles in a way that takes them into account. It does make your life easier if your paths are short and don't have spaces,since it is just easier to navigate the project. But it is not a requirement.Another issue you may run into the path length limit. This is again, old OS limitation, but in many cases file path can't exceed 256 characters. And while sounds stupid, Microsoft does pretty stupid things, and OneDrive location itself is usually already pretty long (it often includes full corporate name in corporate environments). And if you keep deep file structure, it is possible to exceed this limit.

author: Simon
author_rank: Unknown
timestamp: August 12, 2025, 02:08:46 pm
content: Quote from: ataradov on August 12, 2025, 02:02:21 pmYep, that is precisely what happened, its in c / users / simon /..... and the first project I stated in MPLABX refused to work as the path lengths were so long.So I can't get out of "one drive - company name" which is at least one place with spaces and you can't have the one drive folder in C:/ it will make itself a folder in whatever folder you choose but I managed to shave a few chars off the paths and it works.

author: ataradov
author_rank: Super Contributor
timestamp: August 12, 2025, 02:12:37 pm
content: There are ways to work around that. You can create links to that OneDrive location in C (https://www.howtogeek.com/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/).And if you avoid spaces in your own structure, it is possible to avoid spaces everywhere in the project.

author: Simon
author_rank: Unknown
timestamp: August 12, 2025, 03:20:44 pm
content: Well that will most likely be something that I will need the IT company to do as I doubt I have the "power". As it is for normal server folders are mapped as drives, I suspect that is basically the same thing.Anyway, in this case the PIC32CX1025SG41:Code:/* ************************************************************************** *//* MEMORY MAPPING DEFINITIONS FOR PIC32CX1025SG41128 *//* ************************************************************************** */#define FLASH_SIZE _UINT32_(0x00100000) /* 1024kB Memory segment type: flash */#define FLASH_PAGE_SIZE _UINT32_( 512)#define FLASH_NB_OF_PAGES _UINT32_( 2048)#define SW0_SIZE _UINT32_(0x00000008) /* 0kB Memory segment type: fuses */#define USER_PAGE_SIZE _UINT32_(0x00000200) /* 0kB Memory segment type: user_page */#define USER_PAGE_PAGE_SIZE _UINT32_( 512)#define USER_PAGE_NB_OF_PAGES _UINT32_( 1)#define CMCC_SIZE _UINT32_(0x01000000) /* 16384kB Memory segment type: io */#define CMCC_DATARAM_SIZE _UINT32_(0x00001000) /* 4kB Memory segment type: io */#define CMCC_TAGRAM_SIZE _UINT32_(0x00000400) /* 1kB Memory segment type: io */#define CMCC_VALIDRAM_SIZE _UINT32_(0x00000040) /* 0kB Memory segment type: io */#define QSPI_SIZE _UINT32_(0x01000000) /* 16384kB Memory segment type: other */#define HSRAM_SIZE _UINT32_(0x00040000) /* 256kB Memory segment type: ram */#define HSRAM_ETB_SIZE _UINT32_(0x00008000) /* 32kB Memory segment type: ram */#define HSRAM_RET1_SIZE _UINT32_(0x00008000) /* 32kB Memory segment type: ram */#define HPB0_SIZE _UINT32_(0x00004400) /* 17kB Memory segment type: io */#define HPB1_SIZE _UINT32_(0x00022000) /* 136kB Memory segment type: io */#define HPB2_SIZE _UINT32_(0x00003c00) /* 15kB Memory segment type: io */#define HPB3_SIZE _UINT32_(0x00003000) /* 12kB Memory segment type: io */#define SEEPROM_SIZE _UINT32_(0x00020000) /* 128kB Memory segment type: io */#define SDHC0_SIZE _UINT32_(0x00000c00) /* 3kB Memory segment type: io */#define SDHC1_SIZE _UINT32_(0x00000c00) /* 3kB Memory segment type: io */#define BKUPRAM_SIZE _UINT32_(0x00002000) /* 8kB Memory segment type: ram */#define PPB_SIZE _UINT32_(0x00100000) /* 1024kB Memory segment type: io */#define SCS_SIZE _UINT32_(0x00001000) /* 4kB Memory segment type: io */#define FLASH_ADDR _UINT32_(0x00000000) /* FLASH base address (type: flash)*/#define SW0_ADDR _UINT32_(0x00800080) /* SW0 base address (type: fuses)*/#define USER_PAGE_ADDR _UINT32_(0x00804000) /* USER_PAGE base address (type: user_page)*/#define CMCC_ADDR _UINT32_(0x03000000) /* CMCC base address (type: io)*/#define CMCC_DATARAM_ADDR _UINT32_(0x03000000) /* CMCC_DATARAM base address (type: io)*/#define CMCC_TAGRAM_ADDR _UINT32_(0x03001000) /* CMCC_TAGRAM base address (type: io)*/#define CMCC_VALIDRAM_ADDR _UINT32_(0x03002000) /* CMCC_VALIDRAM base address (type: io)*/#define QSPI_ADDR _UINT32_(0x04000000) /* QSPI base address (type: other)*/#define HSRAM_ADDR _UINT32_(0x20000000) /* HSRAM base address (type: ram)*/#define HSRAM_ETB_ADDR _UINT32_(0x20000000) /* HSRAM_ETB base address (type: ram)*/#define HSRAM_RET1_ADDR _UINT32_(0x20000000) /* HSRAM_RET1 base address (type: ram)*/#define HPB0_ADDR _UINT32_(0x40000000) /* HPB0 base address (type: io)*/#define HPB1_ADDR _UINT32_(0x41000000) /* HPB1 base address (type: io)*/#define HPB2_ADDR _UINT32_(0x42000000) /* HPB2 base address (type: io)*/#define HPB3_ADDR _UINT32_(0x43000000) /* HPB3 base address (type: io)*/#define SEEPROM_ADDR _UINT32_(0x44000000) /* SEEPROM base address (type: io)*/#define SDHC0_ADDR _UINT32_(0x45000000) /* SDHC0 base address (type: io)*/#define SDHC1_ADDR _UINT32_(0x46000000) /* SDHC1 base address (type: io)*/#define BKUPRAM_ADDR _UINT32_(0x47000000) /* BKUPRAM base address (type: ram)*/#define PPB_ADDR _UINT32_(0xe0000000) /* PPB base address (type: io)*/#define SCS_ADDR _UINT32_(0xe000e000) /* SCS base address (type: io)*/the ones of note are:QuoteandQuoteSo apart from the high speed ram there are two other things that start at the same address both with a size of 32 kB. I have found mentions of retention memory, I guess that is HSRAM_RET1_SIZE but I have no idea what HSRAM_ETB_SIZE is.

author: ataradov
author_rank: Super Contributor
timestamp: August 12, 2025, 03:30:38 pm
content: Links should be possible to create as a normal user. It may not be in the C root, but some user place would work. It takes 5 minutes to try.ETB is an Embedded Trace Buffer. This is extremely useful debugging tool. It is possible to allocate a portion of the SRAM for a trace buffer that is simple enough that it can be parsed by hand. You don't need any tool support and you can trace execution of the code. Each entry is a 32-bit word containing the branch address and a few bits of other information.From all ARM CoreSight tracing support, I found this one to be the easiest to use and the most useful.