Idea for a EEPROM library (hidden flash-RAM)

As I was reading this topic viewtopic.php?f=3&t=110 I was thinking about how to use this as additional (simulated) EEPROM memory.
As far as I know, the original libmaple EEPROM library used a reserved(?) space of the flash memory to emulate the arduino EEPROM lib.
So my idea is to “highjack” this hidden memory for a new library. The drawback is, that for every MCU type there must be a specific #ifdef (64/128k 128/256k 256/512) and a little testing code for each individual device: Writing and reading back some pattern, dividing the FLASH into sectors and write a good/bad table of the proofed sectors. (Maybe not necessary at all, so if additional flash is available it should work anyway)
BTW: Has someone tried to access to the additional memory of the maple mini clones (STM32F103CBT6) or is 128k the physical limit for that MCU (because stm32f103c8t6 is the “cut down” version)? So the lib would only be useful for the masses if widespread devices can do the trick.

Madias, I have not tried to write over 128KB in the CB chips, but I did confirm the RCT chip, which should have 256KB of flash and 40 of RAM, has at the very least 512KB of flash and 64KB of RAM. I found the extra RAM by chance, because I thought it actually had 64KB, I was using the RET files, that set the stack at 64KB. Then later on reading the specs I realized it should have had 40KB only, but my stack had been at the top end of 64KB all along and it never crashed, so I know the RAM up there was usable.

If you want to test the limit, you can easily write a script that goes writing and reading addresses over that limit, and reading back the values to confirm it was written successfully.
My suspicion is that the CB chip is the limit for that silicon, but who knows, perhaps there is extra Flash or Ram hidden…
In the RCT board I never tried to go over 512KB or 64KB of RAM, but who knows, it is possible that there is even more…

I don’t think we can put anything into the core that relies on hidden features that may or may not work, but we can document how to test if your board has much more ram and rom than its supposed to .

I think the C series are called Medium Density, (the F103RB) may also be Medium Density.

The F103RC and RE and V series and Z series, are High Density devices.

I suspect that there are two completely different silicon fab chips inside the package.

So although the C8 could be a CB, its less likely that a C8 or a CB contains a High density device inside.

We don’t currently have variants for the F or G versions e.f. F103RGT , but it would be easy to add them, so that F103RCT board owners could try the board as an F103RGT

Madias, I just tested that the RCT chip can not read or write past 512KB, with STLink or the Serial bootloader. That is the limit for that silicon.
If I have time later I’ll test on a maple mini later and let you know.

Also if I try to read RAM past 2000FFFF (the 64KB top), the sketch just crashes.

I’ll post maple mini results when I get a chance to test.

Roger, I don’t think we should mislead anyone by setting the core to use higher limits, but it is good to know if they exist.
I.E. I was using the RET linker script with RCT board and works fine, I do know that I am using an option that does not correspond to the MCU in my board, so the decision depends on me to consciously select an MCU different than the one I should.

I think Madias is not suggesting that the core goes over the limit in the C8 boards, but that if extra flash is available, we can make a conscious choice to use it by compiling for the CB, or even an RC if that much extra is available.

victor_pv wrote:
Also if I try to read RAM past 2000FFFF (the 64KB top), the sketch just crashes.

ahull wrote:victor_pv wrote:
Also if I try to read RAM past 2000FFFF (the 64KB top), the sketch just crashes.

and I can even read 496 bytes more, up to 0x1FFFF9FF, which do not even exists according to the datasheet (they read FF by the way)

I suspect the temptation to experiment with writing in that area is now irresistible… however it might be difficult to figure out what, if any effect they have… …there is a chance of course that this may be where things like the unique identifier and the cpu ID live.

You could get out the magnifying glass and take a look at the die shot

You guys should crank up arm-none-eabi-gdb and poke around. You don’t have to write programs to examine all this stuff.

You might want to set:
(gdb) set mem inaccessible-by-default off
This allows you to access addresses outside the official chip memory map.


I’ll have to play with that…

Guys,

I was thinking, that even though we don’t have the Eclipse standalone debugger yet (unless you are on Linux, like andy and Rick), then perhaps we should add a debug menu to at least the Generic STM32F103C boards, that kicks off GDB in a shell window.

There are some nice videos on Youtube by Harvard Uni, that explain how to use GDB on the command line, and I think there would definately be a few people who’d like to give GDB a try if they didnt have to manually run st-util etc

BTW. Thinking about Rick’s posting about OpenOCD. (I will try to reply to that thread when I get chance), that perhaps we’d be better off using OpenOCD than Texane for STLink. However I’ve not looked to see if OpenOCD supports upload (and erase etc) via STlink.

Anyway, just a thought.

PS. Sorry I’ve not had chance to do much on the repo this weekend, but domestic events (the fence between me and the neighbors) needed my attention for the last 2 days ;-(

ahull wrote:and I can even read 496 bytes more, up to 0x1FFFF9FF, which do not even exists according to the datasheet (they read FF by the way)

I suspect the temptation to experiment with writing in that area is now irresistible… however it might be difficult to figure out what, if any effect they have… …there is a chance of course that this may be where things like the unique identifier and the cpu ID live.

You could get out the magnifying glass and take a look at the die shot

RogerClark wrote:Guys,
I was thinking, that even though we don’t have the Eclipse standalone debugger yet (unless you are on Linux, like andy and Rick), then perhaps we should add a debug menu to at least the Generic STM32F103C boards, that kicks off GDB in a shell window.

Not sure if you found this, there is an app note that talks about wear leveling on flash when you use it like eeprom:

http://www.st.com/web/en/resource/techn … 165693.pdf

-rick

Rick Kimball wrote:RogerClark wrote:Guys,
I was thinking, that even though we don’t have the Eclipse standalone debugger yet (unless you are on Linux, like andy and Rick), then perhaps we should add a debug menu to at least the Generic STM32F103C boards, that kicks off GDB in a shell window.

I had modified the stlink_upload to do this but since then I’ve since moved from stlink to mostly BMP:

I have something like this:

# blackmagic probe w/gdb upload
tools.bmp_gdb_upload.cmd=arm-none-eabi-gdb
tools.bmp_gdb_upload.path={runtime.tools.arm-none-eabi-gcc.path}/bin/

tools.bmp_gdb_upload.upload.speed=115200
tools.bmp_gdb_upload.upload.params.verbose=
tools.bmp_gdb_upload.upload.params.quiet=-q --batch-silent
tools.bmp_gdb_upload.upload.pattern=xterm -e "{path}{cmd}" -q -cd "{build.path}" -b {upload.speed} {upload.verbose} -ex "set debug remote 0" -ex "set target-async off" -ex "set remotetimeout 60" -ex "set mem inaccessible-by-default off" -ex "set confirm off" -ex "set height 0" -ex "target extended-remote {serial.port}" -ex "monitor swdp_scan" -ex "attach 1" -ex "x/wx 0x8000004" -ex "monitor erase_mass" -ex "echo 0x8000004 expect 0xffffffff after erase\n" -ex "x/wx 0x8000004" -ex "file {build.project_name}.elf" -ex "load" -ex "x/wx 0x08000004" -ex "directory {source_file}" -ex "tbreak setup"


Hi Rick, most ‘nixes define a TERM or a COLORTERM variable, so you could use some variation of

$COLORTERM -e “st-util” -t “st-link Debugger”

RogerClark wrote:<…>
PS. Sorry I’ve not had chance to do much on the repo this weekend, but domestic events (the fence between me and the neighbors) needed my attention for the last 2 days ;-(

Fences make for happy neighbors.

Yes. Everyone is happy now we have a 2m high fence