# Spark CLI Flash Memory **URL:** \ **Category:** uncategorized\ **Created:** [July 25, 2014, 1:29pm UTC](https://community.particle.io/t/spark-cli-flash-memory/5980 "2014-07-25T13:29:40Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Muez](https://avatars.discourse-cdn.com/v4/letter/m/2bfe46/32.png) [@Muez](https://community.particle.io/u/Muez)\ **Post date:** [July 25, 2014, 1:29pm UTC](https://community.particle.io/t/spark-cli-flash-memory/5980/1 "2014-07-25T13:29:40Z")
Hi all, Is there a way to use the Spark CLI interface to write into the flash memory of the spark core? Does the CLI use the dfu-util tool to write the firmware to the spark core? Muez ---
**Author:** ![kennethlimcp](https://avatars.discourse-cdn.com/v4/letter/k/c0e974/32.png) [@kennethlimcp](https://community.particle.io/u/kennethlimcp)\ **Post date:** [July 25, 2014, 1:32pm UTC](https://community.particle.io/t/spark-cli-flash-memory/5980/2 "2014-07-25T13:32:09Z")
Yup! The `spark-cli` is essentially sending a dfu-util command for the various functions like `spark keys server`, `spark flash --usb` or `spark flash --factory` etc. Maybe added a general function like spark flash flash\_address bin\_file` would be awesome 😉 Take a look at : [https://github.com/spark/spark-cli/blob/master/js/lib/dfu.js](https://github.com/spark/spark-cli/blob/master/js/lib/dfu.js) ---
**Author:** ![Muez](https://avatars.discourse-cdn.com/v4/letter/m/2bfe46/32.png) [@Muez](https://community.particle.io/u/Muez)\ **Post date:** [July 25, 2014, 1:38pm UTC](https://community.particle.io/t/spark-cli-flash-memory/5980/3 "2014-07-25T13:38:24Z")
Hi @kennethlimcp, I was looking at that file a while ago, but the problem is I don’t see those functions getting called from the main ApiClient.js. ---
**Author:** ![Dave](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dave/32/181_2.png) [@Dave](https://community.particle.io/u/Dave)\ **Post date:** [July 25, 2014, 2:25pm UTC](https://community.particle.io/t/spark-cli-flash-memory/5980/4 "2014-07-25T14:25:58Z")
Hi @Muez, The dfu-util stuff for the cli is wrapped by the “dfu.js” module here: [https://github.com/spark/spark-cli/blob/master/js/lib/dfu.js](https://github.com/spark/spark-cli/blob/master/js/lib/dfu.js) It shouldn’t be too tough to extend it to write arbitrary files to arbitrary addresses, just be careful not to nuke your keys! 🙂 Thanks! David ---
**Author:** ![Muez](https://avatars.discourse-cdn.com/v4/letter/m/2bfe46/32.png) [@Muez](https://community.particle.io/u/Muez)\ **Post date:** [August 1, 2014, 9:36am UTC](https://community.particle.io/t/spark-cli-flash-memory/5980/5 "2014-08-01T09:36:44Z")
Hi @Dave, I changed the writeFirmware function to this: writeFirmware: function(binaryPath, leave) {         return that.writeDfu(1, binaryPath, “0x00100000”, true);     }, and then when I Ioad a binary to the Spark Core using: ./spark.sh cloud flash spark\_core\_name path The core doesnot leave the dfu mode. Why do you think is that the case? ---
**Author:** ![kennethlimcp](https://avatars.discourse-cdn.com/v4/letter/k/c0e974/32.png) [@kennethlimcp](https://community.particle.io/u/kennethlimcp)\ **Post date:** [August 1, 2014, 9:46am UTC](https://community.particle.io/t/spark-cli-flash-memory/5980/6 "2014-08-01T09:46:57Z")
Why did you change to `0x00100000`? Also, you changed the `alt` to `1` which writes to the External flash… ~~It seems like you wrote to a memory space which does not exist (max is 0x200000 on external flash) which might be the reason why the core doesn’t reset since the command is somehow invalid.~~ I’m not sure where you are writing to… You might want to refer to the mapped address: [http://docs.spark.io/hardware/#memory-mapping-internal-flash-memory-map](http://docs.spark.io/hardware/#memory-mapping-internal-flash-memory-map) I’m just curious what does the output of the DFU-util say. 😛 ---
**Author:** ![Muez](https://avatars.discourse-cdn.com/v4/letter/m/2bfe46/32.png) [@Muez](https://community.particle.io/u/Muez)\ **Post date:** [August 1, 2014, 9:52am UTC](https://community.particle.io/t/spark-cli-flash-memory/5980/7 "2014-08-01T09:52:54Z")
The arguments of the writeDfu function are the alt dfu option (1 - to select flash memory), the binaryPath, the address where I want to write to (0x00100000 a valid flash address) and leave dfu option. ---
**Author:** ![kennethlimcp](https://avatars.discourse-cdn.com/v4/letter/k/c0e974/32.png) [@kennethlimcp](https://community.particle.io/u/kennethlimcp)\ **Post date:** [August 1, 2014, 9:54am UTC](https://community.particle.io/t/spark-cli-flash-memory/5980/8 "2014-08-01T09:54:32Z")
Can you try `0x100000` instead of `0x00100000`? ---
**Author:** ![Dave](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dave/32/181_2.png) [@Dave](https://community.particle.io/u/Dave)\ **Post date:** [August 1, 2014, 1:50pm UTC](https://community.particle.io/t/spark-cli-flash-memory/5980/9 "2014-08-01T13:50:25Z")
Hi @Muez, That’s because you’re calling `cloud flash ...`, when you should be calling `flash --usb myfirmware.bin` Thanks, David ---
**Author:** ![Raul](https://avatars.discourse-cdn.com/v4/letter/r/958977/32.png) [@Raul](https://community.particle.io/u/Raul)\ **Post date:** [August 6, 2014, 10:23am UTC](https://community.particle.io/t/spark-cli-flash-memory/5980/10 "2014-08-06T10:23:28Z")
Hey, What I think @Muez is attempting to do is. To write to the external flash using the cloud. I too am curious if this is possible and how this can be done using the spark-cli found on github. ---
**Author:** ![Dave](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dave/32/181_2.png) [@Dave](https://community.particle.io/u/Dave)\ **Post date:** [August 13, 2014, 6:47pm UTC](https://community.particle.io/t/spark-cli-flash-memory/5980/11 "2014-08-13T18:47:05Z")
Hi @Raul, Good question! We’ve been thinking about this, and we’ve started working towards it, here’s an example: > @satishgn added the ability to flash firmware over serial, as well as making the OTA process more flexible for writing to arbitrary flash addresses using the same OTA system we have in place already. Look for this to be included hopefully later this summer. 🙂 Thanks, David