Generic STM32F103C8T6 board from Aliexpress for $6.88

The MCU has officially 256KB of flash, and 48KB of RAM, although my test have shown they actually have 512 and 64, like the RET chips.

The only negative in this board, if I remember right, is that the vBAT pin is not broken out, but is instead connected to Vcc.
If you want to use RTC and the lowest possible power, you can not just power the RTC alone, but need to power the whole MCU, and then put it in standby mode, in which it uses only a few uA. On the other hand, the 1117 regulator on board will take 3-5mA quiescent current, so to really save power you need to either replace it, or power the board with a 3.3V supply to a 3.3v pin rather than to going thru the 1117.

The board works fine with the stm32duino bootloader.

But seriously, if at some point I suspect the RAM of Flash are causing me any crash, I’ll the test above.
I did something similar but a smaller scale when I killed the vcc diode in my maple mini the first time, at first I didn’t notice the voltage to the mcu had dropped and I though the flash was getting corrupt, so with st-link I flashed the whole flash with a few binary patterns and read it back correctly each time, and then I went to look at other things and found the actual issue.
But for development, I don’t mind just using the extra flash until it proves to have problems, rather than test it first.

But, out of curiosity, I may run the tests for a few thousand cycles and see what comes of it. If a few thousand cycles in the RAM fail, it was not a reliable board to start with, so better discard it. I think we have up to 10000 cycles in the flash, am I right on that?
I could make a sketch run from RAM (after the 64KB were tested reliable to start with), and run a few hundred cycles of writing all 0, all 1, 0101, 1010 in a cycle. Write, read it back, clear, verify clear, and repeat with the next pattern. If ST indeed test the flash to decide which mcu to sell as 256KB ones, they can’t run many cycles of their test, or they would actually lower the expected life of the flash. Perhaps they run a single cycle, or just a few.

I have an Ugly board I’m willing to sacrifice.

It wont start up from cold boot into the sketch, this seems a common problem with the board so i suspect its a hardware design fault somehow, but i guess it could be all the Ugly boards were made with a batch of reject chips.

Actually, now i think of it, i think Ricks Ugly board is ok…. ummm

Anyway, it works if you upload via Serial and probably works via stlink, as long as you then send the command to Run from 0x800000 from the serial bootloader (stm32flash) or from STLink.. So it would be possible to test the number of erase cycles using the EEPROM lib e.g. in the upper 1k block of flash

Ram testing doesnt harm anything , so i guess anyone can do that, its just a question of how long you are willing to wait

I have an Ugly board I’m willing to sacrifice.

It wont start up from cold boot into the sketch, this seems a common problem with the board so i suspect its a hardware design fault somehow, but i guess it could be all the Ugly boards were made with a batch of reject chips.

Actually, now i think of it, i think Ricks Ugly board is ok…. ummm

Anyway, it works if you upload via Serial and probably works via stlink, as long as you then send the command to Run from 0x800000 from the serial bootloader (stm32flash) or from STLink.. So it would be possible to test the number of erase cycles using the EEPROM lib e.g. in the upper 1k block of flash

Ram testing doesnt harm anything , so i guess anyone can do that, its just a question of how long you are willing to wait

I wrote a sketch that copies section of the flash to the ram between 48KB and 64KB in an STM32F103RCT board.
Remember that MCU is supposed to have only 48KB of RAM, and 256 of flash, so in theory there should not be any RAM over 48KB.

Just to test if the chip was an RET that had defective RAM and got rebadged by STM to be an RCT, I am exercising the RAM.
I’ll probably do another test with the flash later, but for now this is the result of the RAM test.

Methodology:
The sketch copies chunks up to 10KB from the flash to the ram to fill all the positions between 48KB and 64KB, then read them back and compare them to the original value.
The starting address in the flash is incremented up to 4000, then goes back to the start. So on each pass, the starting address is incremented. That results in that the same value is not written every time to the same position, but rather different values from the flash. The bootloader has 8KB in size, and the sketch another 13KB. There may be a few bytes repeated here and there, but I don’t think more than 4000 in a row, but I could also make the range of flash used for the copy wider. The whole idea is to write random numbers that are not exactly the same in each pass, so if a bit fails to hold 0 or fails to hold 1, or an address line is messed up, etc, it should be detected.

I just fired the sketch a couple of minutes ago, and has run about 50k passes with no errors.
I am not using DMA for the copy, because it can run several thousands passes in just a few minutes any way, it is not like I need it to complete within a certain period.

Next is doing the same with the flash over 256KB to 512KB, but run it only for like 50 passes. That shouldn’t shorten the life of the MCU much, while being able to detect any stuck bit.

Ray

Ray

Ray

Ray

Actually I have some thermistors around, I may make it monitor the max temperature reached and display it, then go grab it next day and see how hot it got, and if it ever failed the backyard engineer reliability test

Edit: Even better, I may add a flash testing routine, then make it run outside, monitor the temp and when it sees the temp has reached the maximum and starts to decrease, run the flash test at that time. I have to plan where to leave it, if it gets too much direct sun here in Texas it may get over the 85C spec limit, then a failure wouldn’t prove much.