My question is similar to "New firmware for old core":
but the situation is slightly different.
I have cores from Spring 2014. I'm not using the cloud for anything, but instead locally compile and link code in the following directories:
core-common-lib
core-communication-lib
firmware (which includes my modified Application.cpp)
Which produces (in the firmware/build directory) core-firmware.bin
Questions:
Assuming I grabbed the most recent source for the above folders, does this eliminate the need for (or take care of) the CC3300 patch? Or does that have to be handled separately?
Is there anything else that needs updating, that is not in those three folders? I assume I don't (shouldn't) touch the bootloader.
To which address do I flash the resultant core-firmware.bin? AND WHAT DO THESE TWO LOCATIONS DO???
dfu-util -a 1 -s 0x00020000 -v -D core-firmware.bin
or
dfu-util -a 0 -s 0x08005000:leave -D core-firmware.bin
or
I've seen other addresses for other things (is there a list somewhere that spells them out?)
There are two chips you can flash via DFU, the ARM processor itself and the external FLASH RAM. You can check the memory map to see which one is which, but normally you write the firmware to -a 0 -s 0x080005000. There are multiple copies of the code and a copy of Tinker so it is hard to brick your core.
None of this code handles the TI patch. There are two processors on a Spark Core, the ARM that you write code for and another hidden one inside the TI CC3000 that only TI can write code for. To patch the TI CC3000 you run a special program on the ARM that loads hex data from TI onto the CC3000. This is normally a one-time event, but there are some bugs in the TI part that can reset by re-flashing it. If you connect to the Spark cloud, it will report your TI patch level and offer the patch it from the web IDE.
You might want to update the bootloader (again there is special firmware you download that can load it) since the watchdog timer changed from the original Kickstarter cores until now. If you want to program the bootloader with your own code, you need special hardware like a JTAG controller and shield or equivalent. Spring 2014 cores should be updated already.
The new firmware coming out soon for Photon compatibility is all in one repo (firmware) so your build process will change if you move to that codebase.
But, as far as a memory map, I don’t see one in that document. I see a start of a text description of where things are, but no memory map, and no addresses listed. I’m used to seeing micro-controller memory maps that have all the pertinent data listed in a table. It shouldn’t be hard to come up with, and help eliminate questions like mine.
The cores might have been dated from late 2013 (got them in January 2014). Would they have had the new bootloader? I do have, and have used a ST-Link previously.
There’s a slightly newer firmware but just to have deep sleep feature so if you are thinking of upgrading to newer bootloader, wait for the V0.4 firmware to be released
Hey, thanks for the graphic. That’s what I had in mind.
I do run a slightly (<2 year old) version of FF because I don’t like some of the “features” of the newer versions. Totally O/T and no offense intended to the web folks, but I also do web programming and never design around the latest browser features as it leads to things like this.
