Recently when I was using a 328 UNO I used the arduino-builder and scripts as I prefer using the command line and my choice of command line editor. I think the arduino-builder method allows more configuration beyond what is achievable in the IDE. Currently for my Bluepill project code I’m using the IDE but will switch to the command line method.
I want to rebuild the core code for the Bluepill with certain things such as USB serial disabled. I don’t need the USB serial and if I do I plug a USB-Serial dongle into my board that uses one of the HW serial ports. Not sure what other code I could also remove to save space. I’d like to stick with the Arduino libraries that are about so that I don’t have to do modified cut down versions or write my own support code. Fitting my project and support code into the 64k space is what I want to achieve.
Are there any threads about that talk about doing this or any ideas of how I can reduce the memory foot print? I noticed in the build window of the IDE defines such as -DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG=1 -DSERIAL_USB -DGENERIC_BOOTLOADER. Can I get away with disabling those defines?
If I create a new Sketch with setup() and loop() both empty it comes to 12548 bytes (19%) of program storage space so that’s a lot before I even get started.
Last question will the GCC “strip” tool reduce the size down? I normally use that when building code for Intel CPUs.
In boards.txt you can remove then the -DSERIAL_USB option for the STLink upload method entry.
PS. 64k is quite a lot of code, or perhaps you have a large dataset e.g. some audio
@Stevestrong: I use only STlink for programming but I was under the understanding that is handled by the STM32 part itself in it’s own ROM even if I wipe the Flash contents completely? I will look at the boards.txt file as you suggest but I don’t know if it uses one as IDE always complains:
Could not find boards.txt in /home/USERt/Arduino/hardware/Arduino_STM32-master/examples. Is it pre-1.5?
Although I think Roger mentioned in another topic that’s some sort of warning because of the way his library is currently structured. Where will I find the boards.txt file that needs changing?
@RogerClark: Nothing that big and certainly no audio involved. I do have some RTC code left over from a 328 build which has no righful place in there (it’s an RTC_DS1307 instance) just so it can compile and needs to be replaced and I will use the built in native RTC. Also use SdFat, ADC inputs, 2 HW serial ports, EmonLib, etc. (an unfinished Energy monitor). I’ll need to put it through http://danieleff.com/stm32/map_analizer/ and check it out in more detail to see where it’s going.
Yes, your understanding is correct, according to the datasheet the BluePill’s C8 is 64kB.
In reality it is 128kB.
That is like “the Sum of n from n=1 to infinity equals the infinity” with my understanding, but in reality it equals -1/12.
The 2k I was referring to is the stm32duino bootloader (in flash) which allows to upload over USB DFU. For upload over STLink it is not relevant though.
boards.txt
You can use 128K on blue pill. Try and you’ll see 
[stevestrong – Sun Nov 26, 2017 12:07 pm] –
Wherever possible, avoid the “new” constructor because it will link a huge unwanted part of gcc lib.
I’ve not used “new” in my code but don’t know what the libs are doing.
[stevestrong – Sun Nov 26, 2017 12:07 pm] –
The 2k I was referring to is the stm32duino bootloader (in flash) which allows to upload over USB DFU. For upload over STLink it is not relevant though.
boards.txt
You can use 128K on blue pill. Try and you’ll see
Thanks for the boards.txt link.
I did some searching on the 128k and what you guys are saying seems to be correct. If the board really is 128k then I don’t really have an issue any more if that can be relied on (It’s not a business project). I’ve heard stories about St stuffing up there data sheets before causing grief for engineering companies.
Has anyone uploaded a large random bin image with a known MD5 sum (say ~127 Mb) then read it back out and done an MD5 sum check or better still a byte for byte compare against the original image?
I will look at the boards.txt file as you suggest but I don’t know if it uses one as IDE always complains:
Could not find boards.txt in /home/USERt/Arduino/hardware/Arduino_STM32-master/examples. Is it pre-1.5?
if i get sufficiently tee’d off with the warning message, i ‘touch <directory mentionedboards.txt'(linux)
or just create a boards.txt file in it(win)
srp
[staticmem – Sun Nov 26, 2017 1:10 pm] –
Has anyone uploaded a large random bin image with a known MD5 sum (say ~127 Mb) then read it back out and done an MD5 sum check or better still a byte for byte compare against the original image?
No, but I used a software with a size of 124k and it worked.
[stevestrong – Sun Nov 26, 2017 4:16 pm] –
No, but I used a software with a size of 124k and it worked.
I’m in Steve’s camp.
I remember a post back in the arduino.cc forum where an Op was upset because s/he had so much left-over unused flash and the under-utilization suggested to them that they were using too “big” of an AVR for there purposes.
We all laugh now.
But, what if they had a really good argument? Should they port to a tiny_AVR such as the t85? Is such a concern even reasonable when at that time a _328P uC was less expensive in quantity == 1 when compared to the t85?
The above is all rhetorical but just thrown out to get you thinking; for small hobby projects with uC + board prices around $3 USD, do we even care? I do not. At 100+ commercial units, you better believe I would put on my procurement conscious hat.
Ray
In some rare occurrences the Blue Pill can have 64k, it’s just that the vast majority seem to have 128k because STMs production yield is so high, they don’t have many parts with 50% defective flash which they hoped to sell as the STM32F103C8.
So most BluePill boards have a STM32F103CB on them, but it’s marked as a C8
What if the production techniques are great and the flash yields 128 but there is an “issue” in a page or two? The chip gets marked as 64K and although the other 64K is available, maybe there is a performance issue or a soft error.
I do know that flash tests are not written like RAM tests with a zillion cycles of marching 1’s, 0’s, compliments, alternates, etc. I suspect that production tests will exercise all 1’s and all 0’s and perhaps compliments. Remember, the flash does have an upper limit on writes, so production QA testing would likely be < 1% of the useful life-cycle.
It’s all academic, but if anyone has experience with QA testing on production flash modules, their experience would be good to share.
Clive One has some interesting comments around the middle of the page.
Ray
[staticmem – Sun Nov 26, 2017 1:10 pm] –Has anyone uploaded a large random bin image with a known MD5 sum (say ~127 Mb) then read it back out and done an MD5 sum check or better still a byte for byte compare against the original image?
With stlink you can upload any random data you want to the MCU to fill up the memory, then read it back to verify. I have done it, and worked fine.
Also ran a memory test in the extra RAM on other MCUs, and run a sketch that writes and reads different test patterns to memory, like a typical mem check tool, and run it for hours without issues. Results were somewhere in the forum.
Consensus seems to be the flash and ram are not defective, but rather STM will use a single silicon piece for several products. It is not guaranteed, people has found C8 MCUs that only had 64KB for real, but I haven’t seen anyone find 128KB but with defects.
@Ray, is this the comment from Clive you are referring to?
“…The choice to make 256KB parts resulting from a choice not to spend time testing beyond that, rather than binning devices failing at some point below the full capacity.”
If we go by that, then perhaps anyone wanting to use the full flash should do a full 00 and FF test with STLink (or we can write a testing sketch that runs let’s say 3 or 4 cycles of patterns, 00, FF, 66, AA)
[victor_pv – Tue Nov 28, 2017 3:25 pm] –
@Ray, is this the comment from Clive you are referring to?
“…The choice to make 256KB parts resulting from a choice not to spend time testing beyond that, rather than binning devices failing at some point below the full capacity.”If we go by that, then perhaps anyone wanting to use the full flash should do a full 00 and FF test with STLink (or we can write a testing sketch that runs let’s say 3 or 4 cycles of patterns, 00, FF, 66, AA)
Yes, that is the summary concern in the post I linked earlier.
I am constantly amazed by the low-price of electronics in today’s marketplace. However, one reason that prices are so low is that manufacturers rarely do product burn-ins. Not only are completed products not burned-in, many of the internal components are not burned-in. While the manufacturing processes are very good, they are not 100% and cascading components across multiple manufacturers will inevitably result in a defective consumer product somewhere in the marketplace: this is just a fact of the current manufacturing paradigm. Reputable manufacturers and distributors will replace these products but that does not mean that the process is hassle-free.
Ray
