As it is always the case, many products from Texas Instruments require a CC-Debugger to flash program memory. Bluegiga’s BLE112 module is not an exception. But when one compares BLE112 and CC-Debugger prices things don’t look bright anymore – there is a little sense (if any) to pay $50 US dollars for a CC-Debugger to program an $11 dollar module. Things become even more ridiculous when a hobbyst is simply willing to flash his/her module only once using the code that is already compiled and debugged by someone else. Would it be possible to find a replacement for a CC-Debugger? Yes, but as always, something is to be sacrificed.
There is a great project at Github called CCLib that uses an Arduino which acts almost like a CC-Debugger. Indeed, nowdays Arduinos are very popular piece of hardware and if you are that kind of person who needs to flash a BLE module, chances that you already have Arduino board in stock are pretty high. But even if it is not the case, buying a basic Arduino board still will be much cheaper than CC-Debugger, besides, immediately after flashing Arduino could be used for another project. The solution works just fine, the only downside of this is an enormously long flashing time, this is because Arduino script works literally as a proxy for business logic implemented in Python scripts on a PC side. The datapackets traveling between PC and Arduino are short resulting in tremendous round trips when it comes to uploading or downloading BLE112 memory snapshots. So, to flash 128Kb it takes 1.5 hours! For some people it could be acceptable but we decided to redesign the whole concept of CCLib focusing on highest possible performance.
First, the logic implemented in Python scripts has to be translated to C/C++ and relocated to Arduino side so the data packets would essentially contain packetised binary files including just a little bit of overhead – packet type, packet length, block number, checksum etc. Second, the size of a single packet would need to be as big as Arduino’s buffers are capable to accommodate, this would be achieved by making Arduino’s app to send the size of its RX buffer before actual data exchange takes place. So, the more advanced Arduino board is used, the bigger its RX buffer and the more effective data exchange would be. Third, standard Arduino’s library is extremely slow when it comes to digital in/out which is very critical for this particular application so faster equivalents of those functions would be used.
The PC application would need to have GUI interface, no nasty command lines with pathetic attempts to display a progress bar. CSharp is probably the most popular language now so the app would be designed for Visual Studio 2013 Community Edition which any hobbist can download for free and use without limitations. Of course, everything is going to be opensource, as usual.
The final result of development effort is given below. Additional total 2k lines of source code has been added to the CCLib project effectively replacing Python scripts. On a PC side an app called ‘Arduino CC-Debugger’ has three configuration parameters in CCLibFrontend.exe.config file which are SerialPort, Baudrate and LogPath. All of them must be set to appropriate values once as they pretty much remain unchanged on a given PC. SerialPort is set to a USB-to-Serial port name which appears in Device Manager list upone plugging in Arduino board to the PC. Baudrate is set to 115200 which matches the port speed on Arduino side. LogPath is set to a directory that would contain log file generated by the Arduino CC-Debugger.
<?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name="CCLibFrontend.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=220.127.116.11, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" /> </sectionGroup> </configSections> <userSettings> <CCLibFrontend.Properties.Settings> <setting name="SerialPort" serializeAs="String"> <value>COM3</value> </setting> <setting name="Baudrate" serializeAs="String"> <value>115200</value> </setting> <setting name="LogPath" serializeAs="String"> <value>C:\CCLib-Frontend\</value> </setting> </CCLibFrontend.Properties.Settings> </userSettings> </configuration>
GIU interface is intuitive and self-explanatory, there are only 3 buttons initiating either reading/writing or chip info retrieval sequence. There are fields for displaying the following information: chip ID, flash size, SRAM size, USB support flag, IEEE address, BT address, hardware version and license. Out of all these fields BT address, hardware version and license are kept at a special location in regular program memory so they could be wiped out or replaced, either accidentally or deliberately. That is why it is highly recommended to do a read operation on your module and keep the file as a backup before doing any writing. Also, for the sake of capturing screenshots and doing video presentations there is a ‘Hide values’ tick which, when enabled, shows only first two digits of your BT address and license preventing them from being stolen and at the same time allowing screenshot/video sharing. And finally, the screen form contains a progress bar which keeps an end user updated during lengthy operations. The total operation time is shown in seconds at the right bottom corner.
The Arduino CC-Debugger app accepts either binary (*.bin) or Intel HEX (*.hex) files. HEX files are parsed by another great third-party project, so-called LibGIS for .Net which is made part of the application. If a file is provided in HEX format, it will be converted to binary and written as image.bin. Then before flashing sequence BLE storage, BT address, hardware version and license will be read from the chip and merged with the content of ‘image.bin’ resulting in creation of ‘image_merged.bin’. Memory snapshots are generated by ‘Read’ command and written in binary format as ‘read.bin’. Each subsequent read operation overrides old file if it exists, same applies to ‘image.bin’ and ‘image_merge.bin’.
Physical connection between Arduino and BLE module comprises of three signal lines (DD, DC and RST) and in total requires 5 wires as Arduino uses two GPIOs for DD signal (one pin is configured as input for incoming data, one pin is configured as output for outgoing data ) plus one wire for ground. Mapping these four signals to Arduino’s GPIOs is done in ArduinoCCDebugger.ino in ‘Pinout configuration’ section and can be redefined to something else if needed. The BLE module’s inputs are not 5V tolerant so there must be resistor dividers as shown on the picture below.
Alternatively, a 3.3V Arduino could be used eliminating necessity of resistors. For example, Seeeduino V.3.0 board has 3.3V/5V selector and therefore it doesn’t require resistors when set to 3.3V mode. Another big plus of Seeeduino is two LEDs connected in parallel to RX/TX lines which conveniently provides with visual indication of data traffic over serial interface so no need in external LED which is used in CCLib project.
A BLE module is connected to Arduino via flat cable and 2.5mm-to-1.27mm adapter as shown on the picture below. The adapter could be the one which comes with CC-Debugger, it is also possible to buy it from ebay or simply build.
The full blown ‘ready-to-flash’ setup is provided on the picture below:
The comparison tables below highlight cost factors for all three solutions mentioned in this post:
|Variant I – flashing with original CC-Debugger|
|Item||Flashing time||Price, USD|
|Variant II – using Arduino + CCLib|
|Item||Flashing time||Price||You save|
|CCLib project + Arduino Uno||1.5 hours(!)||Starts from $3 USD at aliexpress|
|Variant III – using Arduino + Arduino CC-Debugger|
|Item||Flashing time||Price||You save|
|Arduino CC-Debugger + Arduino Uno||80 secs(!)||Starts from $3 USD at aliexpress|
|Total||3.00*||46.00 + a lot of time!|
*Note, that you may end up spending 0 if you already have Arduino.
This project also opens the following possibilities:
1) run the code on faster Arduinos and therefore achieve performance close to the original CC-Debugger or even run it on such boards as Particle (formerly Spark) and flash BLE modules from Apple/Android devices via Cloud;
2) in systems where BLE module works as a slave under control of a host microprocessor it becomes very easy to upgrade/update BLE firmware using host controller through its Serial/WiFi/USB/whatever capabilities.
The video summarising development effort is given below: