Where can I use those commands? cmd doesn’t recognise pio.
1 Like
What? What kind of terminal? Neither cmd, powershell, nor WSL recognizes a pio command. Please be more specific.
Are you using PIO from the commandline or VSCode?
1 Like
How does it matter? The vscode terminal is WSL.
Clicking the terminal as I’ve linked above will give you a shell which has the proper PATH environment variable set up.
1 Like
If you run from your ‘normal’ command prompt, and your search %PATH% isn’t set up right so that pio can be found, it won’t work… hence why if you’re using VSCode… just click that last icon that looks a bit like a command prompt, so you get a properly configured terminal to then run any of the pio commands… 
1 Like
I don’t know if it has the same effect, but I went into the PIO Home page and reinstalled the STstm32 platform.
Ah. The re installation worked. Stuff compiles now, and I now have a new issue! 
lol… unfortunately, it actually does, but due to a glitch in vscode (which should be fixed in the 1.32 (EDIT: nope, still playing up in 1.32.1 
) that was released today or yesterday, you can’t see the prompt at first… if you click on the terminal area though, and start typing, it will work… can probably just hit enter for a new line and it should work.
EDIT: Yeah, pressing enter after ensuring the terminal has input focus is enough to liven it into being visible… or you can …
New issue… that’s progress at least! 
1 Like
pfeerick Out of curiosity, do you have a solution for how to adapt the generic STM32F103 build target to make use of the full 128K flash on the chip? I’m pretty sure I have that version of the Blue Pill.
The target that we’ve established to work only allows the program memory to rise to 65,536B.
The DFU features on the stm32duino framework appear to be a ways away from being merged. 
Only a guess atm…
The linker script that bluepill_f103c8.json sets the flash memory size, and bluepill_f103c8_128k.json does not have a valid linker file at present. I do however suspect after a quick look at the stm32duino to so how they account for 64K and 128K that a valid version of the linker file just needs to be changed to specify 128K, instead of 64K as it currently does. i.e, a copy of this file, and the relevant changes made to the 128k json file to point to a new linker file, and the relevant line changed there.
However, when I tried exactly that, I got a Warning! Cannot find linker script for the current target! and the compiler now has stage fright, so I got no idea what I missed editing there… I thought it was a matter of ‘create missing linker file with minor change, update path to it in board json, job done’ … but no, it wants to be … DIFFICULT!
Not to be dissuaded, I decided to go about it entirely the wrong way, and edited stm32f103x8.ld so that it said FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K on line 4, and line 55 of bluepill_f103c8.json to read "maximum_size": 131072, … and well, yes, it did compile and say the right things… but that was entirely the wrong way to do it! 
btw, there is no reason you couldn’t do the same to genericSTM32F103C8.json … I just happened to be poking around in the bluepill_f103c8.json. But the real question would be… does it blend… er, sorry… does it still work!?
PS: these files are located in %userprofile%\.platformio\platforms\ststm32\
1 Like
HRM! That does indeed work, nicely done! 
I suppose that does confirm once and for all that my board has the 128K flash size.
I believe my next question is rather obvious. How can we get a more formal version of this mod integrated into the ststm32 platform? I suppose I don’t understand how the confluence of my usage circumstances has affected the way that PIO STM32 support normally works.
From what I understand, the only “non-stock” modification I’ve made to the platform is to use the maple core and use a “generic” build target spec. (not including the mod we just made to the linker script. )
1 Like
The core and generic stuff is basically fine as that’s just a configuration value.
The ‘hack’ to the board is something I’ll chase up as an issue → PR on the relevant github repo (I’ll link the issue later tonight when I make it)… then hopefully I can also find out why the way I thought I could do it properly and do a PR to include it doesn’t work…
So it does actually work (i.e. the board is running code fine)? I don’t have an STM32F103 handy so haven’t gone further than a compile/concept test. That was really all I was waiting on before opening an issue/PR.
1 Like
Yes, as far as I can tell, all of the functionality is present. I haven’t been able to test it with a program above the 64K size limit, but that shouldn’t be an issue, right?
Fingers crossed, no… but I reserve the right to be proven wrong! 
The issue is here, let’s see where this rabbit hole leads…
1 Like
This seems to be another way to do a hacky linker script redirect, but it is still a band-aid fix as this particular case is a bug in my view.
Sure, but as Max said, that thread is a bit hard to comprehend. At first glance it looks like that fix doesn’t make changes to the same files that we did, but I’m not sure which it is.
1 Like
It’s just a different way to tackle the linker script change… instead of altering the file used by platformio by default, you specify the path to a custom version of the file via the pre_extra_script, and in this instance, it was included in the platformio project directory. That particular issue was about having a custom linker script for a different board, hence the difference in file name, but the theory of operation should still work. And would survive updates to the platform, as your linker script is actually local to your project.