The Spark Core Firmware

Just wanna know what the backup firmware does and when it kicks in or gets updated :smiley:

0x40000	BackUp Firmware Location	128 KB max

@satishgn any idea? :smiley:

@kennethlimcp, The OTA firmware is downloaded to External Flash(0x60000). After reset, the bootloader takes a backup of the current firmware in Internal Flash (0x08005000) to External Flash(0x40000) before copying the OTA downloaded code to the work area in Internal Flash. During this period if a power failure or any dramatic event interrupts this copy process then on reset, the code in the backup area is reverted back. Hope this answers your question!. Thanks.

1 Like

It does :slight_smile: Thanks!

Just wanted to make sure i was understanding this correctly heh.

Haven’t seen how this is being kicked it but would be nice to explore it :smiley:

Dear BDub, I had the same issue with the ,o,d running under Win7 cygwin. I added the windows make to the arm-gcc compiler and the problem went away. To me it looks like it is rooted in the cywin make (I have Version 4.0). Obviously the windows make does everything correctly. So if you want to get rid of your batch file, just install windows make into the gcc compiler directory. If you add it as a separate directory you have to add the path to the $PATH variable so that it is correctly found.

Thanks for the update! I have actually been problem free for a while now when I noticed one day that I didn’t need to clean all every time anymore. I think it may have been due to a change in the make file by Spark, or it might have been when I converted my PATH variable to DOS 8.3 filename structure. Either way I’m enjoying the good life with fast build times now! :smile:

Some history from the other thread where I tinkered with this problem:

1 Like

I’m trying to build and load the firmware for the first time, and have the firmware compiled. I am at the step of loading the firmware onto the Spark Core. I have dfu-util installed and working, it seems.

root@ubuntu:~/Spark/core-firmware/build# dfu-util -l
dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Found DFU: [1d50:607f] ver=0200, devnum=4, cfg=1, intf=0, alt=1, name="@SPI Flash : SST25x/0x00000000/51204Kg", serial=“8D86087F5055"
Found DFU: [1d50:607f] ver=0200, devnum=4, cfg=1, intf=0, alt=0, name=”@Internal Flash /0x08000000/20
001Ka,108*001Kg", serial=“8D86087F5055”

The problem is with flashing the firmware:
root@ubuntu:~/Spark/core-firmware/build# dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin
dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device…
ID 1d50:607f
Run-time device DFU version 011a
Claiming USB DFU Interface…
Setting Alternate Setting #0
Determining device status: state = dfuDNLOAD-IDLE, status = 0
aborting previous incomplete transfer
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08005000, size = 72136
Download [= ] 4% 3072 bytesdfu-util: Error during special command “ERASE_PAGE” get_status

Not sure if this is a possible cause, but I running Ubuntu 12.4 inside a VM on VMware Workstation using the USB emulation.

Any suggestions?

Hi @shmorgan

I think you are having the problem in this thread, for which you need to build dfu-util differently on Ubuntu. As a nice side effect, this makes dfu-util faster!

2 Likes

Hey Dave, I wonder if there was any progress with regards to making OTA updates faster?

Hi @eranarbel,

We haven’t had a chance to streamline the over the air firmware push quite yet, but there are a few good alternatives in the meantime if you have really really slow OTA updates. We still plan on making this faster though. The challenge here is just making sure everything is backwards compatible, but I’m still hoping we can do this sometime during the summer.

Thanks!
David

Compiling remotely / flashing locally via dfu:

  1. Try 'verify’ing on the build IDE, (refresh the page, bug), then click “download binary” next to the project name
    OR

  2. Install the CLI ( https://github.com/spark/spark-cli ), and use spark cloud compile to get the binary locally

  3. Then put your core into dfu mode

  4. Then you can flash locally with spark flash firmware your_binary.bin

1 Like

Compiling everything went just fine till:

Building file: …/src/spark_wiring_interrupts.cpp
Invoking: ARM GCC CPP Compiler
mkdir -p obj/src/
arm-none-eabi-gcc -g3 -gdwarf-2 -Os -mcpu=cortex-m3 -mthumb  -I…/inc -I…/…/core-common-lib/CMSIS/Include -I…/…/core-common-lib/CMSIS/Device/ST/STM32F10x/Include -I…/…/core-common-lib/STM32F10x_StdPeriph_Drive
r/inc -I…/…/core-common-lib/STM32_USB-FS-Device_Driver/inc -I…/…/core-common-lib/CC3000_Host_Driver -I…/…/core-common-lib/SPARK_Firmware_Driver/inc -I…/…/core-communication-lib/lib/tropicssl/include -I…/…/
core-communication-lib/src -I. -ffunction-sections -Wall -fmessage-length=0 -MD -MP -MF obj/src/spark_wiring_interrupts.o.d -DUSE_STDPERIPH_DRIVER -DSTM32F10X_MD -DDFU_BUILD_ENABLE -DRELEASE_BUILD -fno-exceptions -f
no-rtti  -c -o obj/src/spark_wiring_interrupts.o …/src/spark_wiring_interrupts.cpp
…/src/spark_wiring_interrupts.cpp:59:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:60:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:61:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:62:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:63:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:64:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:65:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:66:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:67:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:68:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:69:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:70:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:71:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:72:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:73:7: error: expected primary-expression before ‘.’ token
…/src/spark_wiring_interrupts.cpp:74:7: error: expected primary-expression before ‘.’ token
mingw32-make: *** [obj/src/spark_wiring_interrupts.o] Error 1

Here is a snip of the source code:
//Interrupts
 const uint8_t GPIO_IRQn[] = {
  EXTI0_IRQn,     //0
  EXTI1_IRQn,     //1
  EXTI2_IRQn,     //2
  EXTI3_IRQn,     //3
  EXTI4_IRQn,     //4
  EXTI9_5_IRQn,   //5
  EXTI9_5_IRQn,   //6
  EXTI9_5_IRQn,   //7
  EXTI9_5_IRQn,   //8
  EXTI9_5_IRQn,   //9
  EXTI15_10_IRQn, //10
  EXTI15_10_IRQn, //11
  EXTI15_10_IRQn, //12
  EXTI15_10_IRQn, //13
  EXTI15_10_IRQn, //14
  EXTI15_10_IRQn  //15
 };

// Create a structure for user ISR function pointers
 typedef struct exti_channel {
    void (*handler)();
} exti_channel;

//Array to hold user ISR function pointers
static exti_channel exti_channels[] = {
    { .handler = NULL },  // EXTI0 <== ERROR OCCURS WHEN IT HITS THIS LINE
    { .handler = NULL },  // EXTI1

This problem came up with someone else earlier without an answer. I thought I knew ‘C’ pretty well, but I don’t understand the syntax involved in the “.handler” thing (if I were the compiler I might complain as well). Any of the developers know anything about this? What’s trying to be accomplished? More straightforward way to write that code? How to fix the error??
Thanks!

BTW, compiling on XP but the earlier fellow was on linux, so it’s probably not be the environment.

1 Like

Oh this looks familiar! I think I found the answer for this earlier, brb!

Resolution level sub 5-minutes!

1 Like

Thanks for the tip on field designators. I’ve never used them, but found reference to them here:
http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/Designated-Inits.html#Designated-Inits

The toolchain that I used to build this is found here:
https://launchpadlibrarian.net/170926686/gcc-arm-none-eabi-4_8-2014q1-20140314-win32.zip

Is there a better / more standard supporting toolchain available for windows?

BTW, replacing {.handler = NULL} simply with {NULL} does compile ok. Have you verified that there are no side effects to doing this?

2 Likes

you really should try again on linux, you’re in for a world of pain programming arm/avr on windows.

I’ve been using the toolchain on Windows for months, pain free! :stuck_out_tongue:

well if you know what you’re doing perhaps, but for a noobie its difficult to see if its cygwin and windows filesystem oddities or your sketch that’s the problem.

@sej7278, so maybe that’s the trick… I don’t use cygwin and got everything working just fine, everytime. :wink:

1 Like

While I was waiting (not too long) for the Spark boards I got an Olimex STM32-H103 to play with. Having plenty of PIC experience but zero ARM I found that (free) Windows development tools for ARM were hard to come by. I played a bit with Eclipse but found it hard to set up. In fact I almost gave up on the whole thing.

Then I happened on to this weirdly named (free) IDE called CooCox, and since I didn’t have anything else working, gave it a try. To my surprise it was a fairly easy to setup the toochain and IDE, compile and link a demo file, and download via JTAG to the Olimex board. Debugging seems to work ok too, as far as I tested it at least.

Here are some links:
CooCox:
http://www.coocox.org/CooCox_CoIDE.htm

Compiler Suite:
https://launchpadlibrarian.net/170926686/gcc-arm-none-eabi-4_8-2014q1-20140314-win32.zip
(Need to fix the .handler = NULL problem file for it to compile??? see above)

ST-Link/V2 JTAG:
http://www.digikey.com/product-detail/en/ST-LINK%2FV2/497-10484-ND/2214535

I was able to program the Olimex board with the Spark (hex I think?) file, but the Olimex board is lacking external SPI flash and I hadn’t yet wired that in, so don’t know if it would have worked or not (I have a spare CC3000 but that’s not wired in yet either).

Next step will be to figure out how to download to (and debug on) the spark core. Tips anyone?

Hope this might give someone else a possibly better starting point than I had.

(BTW - I like Linux, I have a dedicated box doing full time data acquisition sitting right beside me, but most of my desktop stuff is still Windows.)

1 Like

hi i cant working. it return me “dfu-util is not recognized as an internal…”. What can ı do ?