Hey,
I’ve read https://community.spark.io/t/sqlite-inside-spark/248/8 and I’m trying to figure out how do I write and read (code-wise) from that spare memory (external flash, about 1.5M free for use).
Is there an example for it?
2 Likes
@dorongutman, thanks for the question. Right now, it’s not possible to write to external flash through the standard web IDE. We’ve got a task in the backlog to create libraries for writing directly to external flash, but it’s not yet implemented. In the meantime, if you are an advanced user and want to write to it directly in firmware, you can follow this memory map guide for reference:
http://docs.spark.io/#/hardware/memory-mapping-external-flash-memory-map
Does that help answer your question? If not, please follow up and I’ll make sure you get a more comprehensive answer.
@will Is it SPI flash? Which (unexposed) pins are MOSI, MISO, SCLK and SS on? I’m sure I could whip something up to get it rolling. It’s almost required for this OLED display I’m writing a library for.
Hey @will, thanks for the answer.
It doesn’t give me the access I was hoping for (via a library/method), but at least I know it’s in the works. I don’t see myself hacking away at the register addresses in the mapping you provided at this point.
1 Like
Yup, I’ve seen that. I just need to know how exactly it’s connected up to the STM32! 
You guys are already obviously using it, so I’m sure it’s in the code somewhere. It wouldn’t be too hard to make it user accessible from there.
1 Like
Hey guys,
Any update on this front?? Thanks
Not officially supported yet, but if you want to live on the edge:
I want to use this as well for my LCD project. One thought that did come up was this:
Lets say they add the functions to write and read from flash memory user area.
Lets also say that we are going to be storing a large amount of data (1meg).
It seems that we are going to need to write another app from our actual program first. This app will allow us to either use serial or TCP to upload our data to flash first so we can get that large amount in there. Then we can load in our actual app to use that data for reading.
seulater, I totally agree, like a “loader” app. I don’t believe DFU-Util can do that directly so we need an app, both on the Spark (to receive and flash) and on a PC (to prepare and send). Not sure how the “image” will be created as I suspect it will contain images/icons/sprites and fonts. I would be cool to use the existing remote flash on the Spark but with an addition to select the core or externl eeprom as targets, since the code already takes care of transmission/verification, etc. Any thoughts?
1 Like
dfu-util can write directly to the flash if I’m not mistaken. It shows up when you list devices and I believe @mohit or @Dave said it worked.
Instead of writing a loader app to do it over serial, you could convert your data to a C Array of bytes and store it one chunk at a time as a const in a sketch that copied it over to the flash. If it’s semipermanent that’s the simplest solution. 
3 Likes
This is correct, the bootloader (dfu mode) will let you write directly to the external flash via dfu. Just don’t write over the keys or factory reset. Just use “-a 1” when doing dfu, and stay above the factory reset area…
The bottom “0x80000” of the external flash is used for stuff like keys and over the air updates, but the rest is safe.
Yeah that’s right, duh! That’s how you get the keys and factory reset firmware on there.
Hey @Dave, does the boot loader have the ability to re-write itself from dfu-util? Or can it be “unlocked” so a user app could rewrite it?
That is great then! However, writing out in chunks seems very painful. What’s the largest chunk size? And the question remains as to what is the best, most universal structure to use. I know, I know, that question is rhetorical since it really depends on the application. I am thinking outloud! 
Using dfu-util you could write all the data at once.
Writing it in chunks from an array in a sketch would be compile size of just the flash library - 128K. In practice I found I had around 60KB of space for bitmap data with my Digole library.
timb, even with 60KB, that’s not too bad. It would be even nicer if we could see that new digole library (LOL!)
I’m working on it this evening, waiting for my buddy to bring my 1.3" Digole display back; he should be here in a couple of hours (I had lent it to him for a project after I got the color unit). Just ironing out problems with this memory display while I wait.