Reducing Bluepill flash memory usage

Post here first, or if you can't find a relevant section!
User avatar
mrburnette
Posts: 2048
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Reducing Bluepill flash memory usage

Post by mrburnette » Sun Nov 26, 2017 5:20 pm

stevestrong wrote:
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

User avatar
RogerClark
Posts: 7545
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Reducing Bluepill flash memory usage

Post by RogerClark » Sun Nov 26, 2017 8:50 pm

BTW.

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

User avatar
mrburnette
Posts: 2048
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Reducing Bluepill flash memory usage

Post by mrburnette » Tue Nov 28, 2017 1:59 pm

... this 64 vs 128 flash issue may be more complex since no one has addressed the QC issue.

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

victor_pv
Posts: 1793
Joined: Mon Apr 27, 2015 12:12 pm

Re: Reducing Bluepill flash memory usage

Post by victor_pv » Tue Nov 28, 2017 3:25 pm

staticmem wrote:
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)

User avatar
mrburnette
Posts: 2048
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Reducing Bluepill flash memory usage

Post by mrburnette » Wed Nov 29, 2017 1:35 pm

victor_pv wrote:
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

Post Reply