This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Firmware update with CC2540

Other Parts Discussed in Thread: CC2540

Hi

Is there any firmware update possibility for the CC2540 except the debugger/programmer?

In our products we would like to see at least the USB firmware update possibility without special hardware like the debugger. In one of the BLE marketing articles was mentioned even a RF version via BLE - too bad I don't remember the article's address, neither the source.

Checked the hex files produced for the keyfob and the dongle from the devkit and i've seen that it covers all the 256k of the flash memory so the debugger writes directly to the flash the full firmware via SPI (so it's hardware solution which does not fits our needs)

The TI libraries are quite complex, with a lot of internal variables and what I want to know is if it's possible to reallocate easily the user code to a different starting address, keeping the first 16-32kbyte free without interfering with those libraries and keeping that space for a simple USB firmware updater (what would be started only in special cases - maybe with a jumper)

regards,

B.

  • The CC Debugger is required for firmware update of the CC2540.

  • I am afraid this is not a good answer - CC debugger is for development and not for production or end-users.

    There are many reasons:

    - CC debugger has a proprietary protocol (found some description in swru191b.pdf)

    - CC debugger + TI programmer cannot be automated for production

    - users who are buying a product based on CC2540 cannot be forced to buy a CC debugger as well just to reflash with a firmware update

     

    For production and end-users a different solution is needed - for example via USB (like: http://www.usb.org/developers/devclass_docs/usbdfu10.pdf

    To implement something like this we need to be sure that all libraries/functions (osal/hal etc. and specially the BLE stack which comes precompiled) can have different mappings without interfering with the current functionality. We can find that via trial and error but if any TI employee or any user who worked with this chip knows the answer it would be nice to know it before doing a few weeks work just to find it out.

    regards,

    Brown.