In my quest to find a low cost programmer for the CC2540 and CC2541 series of Bluetooth Low Energy Soc devices, commonly used as BLE beacons, I bought a device sold as a “Zigbee debugger emulator” from eBay.

On paper this device looked very promising, it contains a Silicon Labs C8051F320 which is the same as used in Texas Instruments own CC-Debugger, and it also claim to emulate the Ti SmartRF04EB device, which is part of TI’s BLE evaluation board.

The board arrived a few days ago, and on plugging it into my PC, it was detected as a SmartRF04EB device, and after I downloaded and installed TI’s SmartRF Studio, the software recognised the board and indicated that the firmware was out of date and needed to be updated by SmartRF Studio.

As it appeared that the board would not work with SmartRF Studio without doing an update, I pressed the button, but the update failed, with a message about needing to change some link settings.

The board had 3 empty pins on it, which looked like a jumper could be connected, so I soldered on 3 pins and carefully checked with a current meter that shorting the middle pin to either of the outer pins, would not draw a large current.

The connecting 2 pins seems to cause a LED to light up, labelled run, and connecting the other 2 pins didnt seem to do anything, which I presume is the default condition.

In “run” mode the USB device vanished from the PC, and I was unable to update, nor did it update with the lump link in the default position

Undeterred, I did some research and found what appeared to be the original supplier details on this board.

http://item.taobao.com/item.htm?spm=a230r.1.14.170.2MpCkJ&id=18594452898&ns=1&abbucket=2#detail

Which seemed to contain the pinout for the 10 pin connector to the BLE module, which seemed identical to the pinout of the TI CC-Debugger.

So I wired the programmer to a HM10 (CC2540) using Reset, clock, data, power, gnd and power sense.

But unfortunately Smartrf Studio still didn’t show the SmartRF04 as having any devices connected to it.

Using an oscilloscope I looked to see if the Reset line was being toggled at any time, or whether the data or clock lines were changing, but none of them were. So my best guess is either the connection required are different to those published on the original supplier website, or the board is defective, or there is a chance that my attempt to update the firmware failed and caused problems. However I don’t think its a firmware update issue, as the device still appears on USB as before, and SmartRF Studio still reports the programmer and its version number.

Its possible that if the firmware on the C8051F320 was updated to a newer version it may work, but that would require a Silicon labs programmer, which would defeat the reason I bought the board, i.e because it could be a budget programmer for CC2540 and CC2541 devices.

Since I ordered this device, 3 or 4 weeks ago, some clone CC-Debuggers have come onto the market for $16 USD (21 AUD), so I have now ordered one of those, and I will post again when it arrives and hopefully I will finally be able to replace the firmware on my BLE modules

Last week, one my my clients changed their online payments processor to eWay, but the eWay plugin did not seem to work on the custom version of OpenCart which we had created from them.

Cutting to the chase, I eventually tracked the down a bug in the eWay plugin for OpenCart 1.5.x which had been caused by the use of a JQuery function that had been deprecated since JQuery 1.7.

I alerted eWay to the issue last week and it has been forwarded to their dev team, along with my fix; but at the time of writing, eWay have not released a new version of the plugin containing the fix, so I thought it was worthwhile publishing the fix here, in case anyone else has the same problem.

You can download the update version here eway-opencart-rapid-3-1-transparent-redirect-module-1.1.4-rogerclark.net

Some background..

We built a custom website for www.1300TonerInk.com.au starting development back in November 2014. TonerInk had already had some initial development produced by another company, using OpenCart V 1.5.6.4 however it did not meet their needs as all.

The key criteria to selection of eCommerce solution was that it needed to have an existing payment gateway plugin for SecurePay, who are a division of Australia Post. And OpenCart had been chosen by the previous developers, and we agreed that this seemed a suitable choice for the client.

To make the site mobile friendly we used the oc-bootstrap theme which seemed to work fine, and development continued on and off until March 2015 when the site was given its soft launch.

Unfortunately it soon became clear that the SecurePay plugin for OpenCart had serious issues and did not work with V 1.5.6.4 and the client opted to switch to using eWay as their payments processor.

But the eWay plug-in also failed to work on the site, with the plugin failing to render on the Checkout page.

Debugging was difficult, because the way OpenCart uses PHP files as template. No PHP errors were being logged or displayed on screen, but no output seemed to be rendered onto the page.

Just to complicate matters, the eWay plugin must be running on server via https (SSL) with a valid SSL certificate. So the only machine that it could be debugged on was the internet web server its self.

Eventually by a process of elimination, the error was tracked down to being in the Javascript code in the view code eWay.tpl, and on closer investigation, the code that handled the click event from the Confirm button seemed to cause the plug html not to be displayed at all.

On closer investigation, the function that was causing the error was live(); which I’d personally never used or even heard of, mainly because its been deprecated since JQuery 1.7!

The reason that the default install of OpenCart does not exhibit this problem, is that it uses JQuery 1.7, where although the function is deprecated, it was still present  – as it didnt get removed until JQuery V1.9

The simple solution was to replace live() with on() as suggested in the JQuery API docs.  http://api.jquery.com/live/

To confirm whether this fix would be applicable to all versions of OpenCart 1.5 – for which the plugin was intended, I confirmed which version of JQuery 1.7 had the replacement function of on() http://api.jquery.com/on/  which it did, as it was introduced in JQuery 1.7 when live() was deprecated.

I’m hoping that eWay take this fix onboard, and hopefully credit me with finding and fixing, something which has been a possible issue since they originally wrote the plug, but at the time of writing I’m still waiting for feedback from their dev team or to see an updated version posted to the OpenCart Extensions page

http://www.opencart.com/index.php?route=extension/extension/info&extension_id=9294

Changes were made to the Arduino IDE in version 1.6.2 which prevent the STM32 files from compiling. This article describes a work around that solves this problem.

From Arduino 1.6.2 onwards, the IDE no longer contains support for ARM based boards, this includes the Arduino Due, when it is first installed. A few feature called the “Boards Manager” was added, in 1.6.2 and all non-AVR based boards now need to be installed after the IDE has been installed and run for the first time.

The issue with this, is that the STM32 processor is an ARM M3 series device and requires the ARM compiler, which had previously been part of the default install of the IDE from version 1.5.0 to 1.6.1

The work around is to install the Due using the Board Manager.

On the Tools menu, select Board and then Boards Manager

In the Boards Manager popup, click on the Arduino SAM board (second in the list at the time of writing), and press the install button.

This will download the ARM compiler and the Due source files as well as other tools needed for the Due

Once the install is complete, the STM32 boards should work again.

For those interested in some other technical details…

Not only is the ARM compiler not installed by default, but all of the compilers, both AVR and ARM, have been moved and are no longer installed in  Program Files (on Windows machines), but are instead stored in the individual user’s Application Data (AppData) Roaming profiles folder.Aside from issues about this practice not following Microsoft’s guidelines for the use of this folder and the fact that the compilers are likely to be synced to Microsoft’s cloud drive for anyone signed into Windows with a Microsoft account…The other problem is that the STM32 files (platform.txt), contain the path to the compiler in its original location (in Program Files). Fortunately, after user feedback, the IDE team added a work around for “Legacy” board support, by the use of a new file called platform.rewrite.keys.txt What this file does, is effectively do a search and replace on text in platform.txt in version 1.6.3 + so that the path to the compiler can be replaced with the path to its new location.For STM32 the file looks like thisold.0.compiler.path={runtime.ide.path}/hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1/bin/
new.0.compiler.path={runtime.tools.arm-none-eabi-gcc.path}/bin/One thing to note with this “rewrite keys” mechanism is that it doesn’t seem to work where the text to search contains user defined variables. Specifically the compiler version used to be defined separately in platform.txtbuild.gcc_ver=gcc-arm-none-eabi-4.8.3-2014q1with {build.gcc_vers} being used in the compiler path definition.So the platform.txt had to be changed to reference the compiler version directly for the compiler path, rather than via the substitution.

Conducting some accelerated batter life test on a HM10 BLE module as an iBeacon, revealed some disappointment battery life results.

The HM10 and HM11 are popular Bluetooth Low Energy modules based on the Ti CC2540 and CC2540 BLE SoC device.

Most HM10 and HM11 devices seem to come pre-installed with with “HMSoft” from a Chinese company called “Huamao Technology CO,. LTD.”

I was interested to determine the battery life of these devices operating as an iBeacon, so I decided to do an accelerated long term test, using two AAA Energizer cells to power the module.

To accelerate the test, I changed the Advertising period using the AT+ADVI command to the minimum time between transmissions, which is quoted as 100ms using the command  “AT+ADVI0”

Power use was minimized by using AT+ADTY3 to make the device non-connectable and AT+DELO2 and enabling auto sleep mode AT+PWRM0

0.44mA Digital current meter

0.5mA Analogue current meter

As far as I can tell the batteries I tested with were standard Energizer E92 / AAA http://data.energizer.com/PDFs/E92.pdf

Looking at the spec, the batteries should have over 1000 mAH on the very low current load that the BLE beacon consumes, however the quoted capacity is at a final voltage of 0.9V, which would give 1.8V for 2 batteries, and is lower than the minimum working voltage for the CC2540 as shown in the spec on the device from TI http://www.ti.com/lit/ds/symlink/cc2540.pdf

The time versus consumption graphs from the battery spec PDF show that at 10mA constant discharge that the battery should last 100 hours, which equates to 1000mAH. However for lower currents there is no data on the graph, as 10mA is the lowest value shown.  However if at lower currents, the capacity followed the same trend line, the capacity would be well in excess of 1000mAH.

At 0.5mA on a 1000mAH battery, I had hoped that the beacon would run for around 2000 hours,  which is nearly 12 weeks. This would extrapolate to around 10 times as long, using normal broadcast rates, of 1 per second, i.e 120 weeks or over 2 years.

However to my surprise, after just over a week, when I measured the voltage on the batteries, I noticed that they had dropped to a combined voltage of 1.9V and the beacon had stopped functioning.

So why has the battery life been magnitudes of order less than anticipated. Well, at the moment I don’t know. There are a number of possible causes for this problem.

1. The batteries were not full when I started.
   Although I took them out of a packet of 20 AAA cells, there is a chance that I’d accidentally put a used battery back in the packet, however this seems unlikely
2. The batteries are elaborate fakes. I bought from a reputable local store, but its possible that somehow fake batteries have got into the supply chain, and perhaps normally no one double checks their capacity.
3. The current measured by my digital and analogue meters was incorrect because of the way that current is taken in pulses rather than being constant.
   This seems the most likely cause at the moment, and needs more research. The “Active Mode Tx” current in the CC2540 spec is 24mA, which would mean for a average current of 0.5mA that the duty cycle would need to be around 1/50 of the total.
   The only way to accurately determine the real power requirement is to monitor the current using an oscilloscope to measure the voltage drop across a low value resistor e.g. a few ohms, connected in series with the HM10 module, then integrate the area of the voltage pulse and calculate the average current.
   I will follow up on this.
4. Operating the beacon at fast update rates (10 per second), may substantially change the way in which the module operates. It may not be fully hibernating. However this seems unlikely.

Where to from here

Well.

1. I’m starting the test again, with a brand new pack of unopened Energizer AAA batteries.
2. I will need to build a small test rig with 10 ohm resistor in series with the battery, and use my oscilloscope to look at the pulse nature of the current consumption
3. Keep thinking of other possible reasons why the results differ so much from the predictions

Watch this space.

The LeafLabs Maple bootloader has a number of shortcommings which I have addressed by making a new version which dovetails with new features in Arduino STM32

The Maple bootloader was originally written by LeafLabs for their Maple and Maple products.

It allows uploads via USB using the DFU protocol. (DFU meaning Device Firmware Upgrade)

The existing bootloader had a number of issues, but the main reason update and improve the existing bootloader was that it requires the Arduino sketch to allocate 3k of RAM to the bootloader, even though the bootloader doesn’t run after the sketch has started to be run.

The reason that the sketch could not use any RAM below the first 3K, is because the bootloader has an option to upload a sketch into RAM and run from RAM. This feature was able to survive a soft reset, because regardless of whether the bootloader had just uploaded to Flash, or to RAM, the code always checked for a magic number in the upload to RAM start address.

However the magic number wasn’t that magical, and was just a check of the first 4 bytes, of the sketch, which are the STM32 Stack Pointer vector, which the STM32 loads into the SP after it boots.

And this number could be a variety of addresses, hence the code was only able to test 13 of the 32 bits of the first 4 bytes, hence the chances of the memory containing a seemly valid magic number where high enough for the bootloader to frequently think that variables we the magic number

The other other improvement that can now be made to the bootloader is reduction of size from 20k to under 8k. This has been achieved by using a bug fixed version of the bootloader, as a starting point, which could be compiled using the optimise for size compiler setting “-Os”

So with the compiler now less than 8K, the start location for the sketch upload could be lowered by 8k, hence giving the sketch 8k more room.

Initially, I just changed the Flash start settings in the bootloader, and made changes to the Arduino STM32, code and linker settings to compile for this new start address, (0x8002000 instead of 0x8005000). However after a discussion with @VictorPV on the Arduino forum, we realised that a better solution was to add another upload mode to the bootloader, and to retain the existing upload to 0x800500 rather than to replace it with the new address

We realised that the bootloader published 2 possible upload types using the AltID numbers 0 and 1, where Alt ID 0 = upload to RAM and Ald ID 1 means upload to Flash (at 0x8005000), and that the Alt ID is specified in the boards.txt and is passed via plaform.txt and finally to dfu-util

So if I added another DFU profile (Alt ID 2), it would be possible to make a bootloader that was backwards compatible with the existing bootloader for flash uploads

The only difference in functionality to an existing function was to the RAM upload.

For upload to RAM, it was only possible to run a sketch in RAM immediately after an upload. Because after a soft reset, it was not practical for the bootloader to determine by looking in the RAM, whether the last upload was to RAM or to Flash (as described above)

After a soft boot, (reset button being pressed or the sketch resetting the microprocessor), the code won’t run code in RAM because a variable records whether there has been a DFU upload.

The code then first check if there is a valid magic number in 0x8002000 and runs the code if present. If no code is found in that address it checks 0x8005000 and runs the code if found at 0x8005000

To prevent the code at 0x8002000 being run, which is left over from a 0x8002000 upload followed by a subseequent upload to 0x8005000, before code is uploaded to 0x800500, the code at 0x8002000 is cleared.

Note. The flash page size on the STM32F103 series is 2k, hence not just the first 4 bytes of 0x8002000 are cleared, a 2k section is cleared and reading the flash memory reveals that its filled with 0xFF, by nature of the way the Flash memory work.

The other improvement that has been made is the build process for different targets.

In the original Leaflabs maple-bootloader repo on GitHub, there were separate branches for each target board. This has resulted in code fragmentation, where bug fixes have been applied to one branch and not others.

To resolve this problem, I took code from the “mini-boot” branch of https://github.com/jonatanolofsson/maple-bootloader and created a new repo.

The mini-boot branch is for the Maple mini board, and seemed to have the most up to date and bug fixed code. Jonatan Olofsson had mostly merged the fixes from one target into another, but when I diff’ed the various branches it soon became clear that the code was actually quite divergent, but that the mini-boot branch seemed to be the cleanest.

I checked an unchanged version of the mini-boot branch into my repo, so that its technically possible to diff my changes and re-apply to the mini-boot branch if anyone wants to do this at a later date. However I suspect that will never happen.

I did also try to contact @jonatanolosffon via github but so far he has not responded to an issue I posted.  (unfortunatly he has not allowed issues on his fork of maple-bootloader, so I can’t send him an issue directly.)

Getting back to build targets… I have modified the Makefile to add targets for Maple mini “maple-mini” and also “maple-rev3” which are controlled using a #define in the makefile via a define in the  compiler flags (CFLAGS).

Then in config.h there are blocks of config using #ifdef to specify the things that are different between the boards like the GPIO pin for the USB disconnection hardware (aka DISC) and the LED and the Maple “button” (which is used to enter the perpetual bootloader mode).

At the time of writing, this config system does need to be improved, and config settings need to be added or Maple rev3, however it does work for maple-mini and will be easily updatable for the other target

Hence

make maple-mini   builds for the Maple mini board

make maple-rev3 is defined as a build target, but lacks a config block at the moment

I will add maple-ret6 and other boards at a later date, as required

All the code and sources have been pushed to GitHub , https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/usb_bootloader/STM32F1

including a binary for the Maple mini

I finally received the 2 Spark aka Particle, Photon boards today.

I ordered 2 of these way back at the end of last year when one of my clients was interested in doing some environmental monitoring using wifi and an IoT device.

Initially delivery time was March, but they finally arrived now (June).

I’m not sure if I should have expected more, but they arrived in a plain white padded bag, albeit in custom made matchboxes, but with no other paperwork than the shipping note.

But I’m used to receiving all sorts of devices from AliExpress and eBay in similar packaging (less the matchboxes)

So. What do to next. Googling “Particle Photon” just takes me to their store.

After searching a bit more I find their landing page site, but that seems to take me back to the store.

But eventually I found some instructions http://docs.particle.io/photon/

So… It seems to say I need an App for my phone. So I try to install it on my iPhone… But, oh no, it needs the iOS 8, and my old phone is known not to work well with iOS 8, so I’m still on iOS 7.

So…. That’s a fail then.

Ok. How about going to their site and not using an App.

Well, you are greeted by a site that just has a login / register box. No information, wiki no forum. You must create an account.

At this point, I’m afraid they lost me, I don’t register for stuff unless I know what I’m getting and why. I normally expect to be able to read stuff and perhaps have some basic features without needing to sign my rights away. After all, if JSFiddle can manage it….

So were does this leave things.

Well, after pressing the two buttons in various orders, and looking at the windows device manager, I can see that it initially appears as a Spark Photon, and loading the drivers this gives a usb serial device

But more interestingly, if you hold down the other button and press reset, the board enumerates on USB as a DFU device.

The problem is that windows won’t use this DFU device, unless you load a driver (well, you need to associate the USB VID/PID with the built in Windows DFU driver. It doesnt look like Spark aka photon have a signed driver for this (well I can’t find one). There are some work arounds on Github e.g.https://github.com/hpssjellis/dfu-util-windows-spark-core-photon

But I that repo has not been touched for 5 months and didn’t look complete

To be honest, I know how to create a driver association, as I can use the same system that we used on Arduino_STM32, but it would be good, if I didn’t have to rebuild a special version of WMI to install the DFU driver for the Photon, after all its a commercial product.

I feel I’ve wasted an hour on this and got nowhere, and my time would be better spent on the ESP8266, as even though its less polished, it does work ! and is a fraction of the price.

I often get asked about why the USB Serial doesn’t seem to work on Maple mini or generic STM32F103 boards loaded with the STMduino-bootloader.

If you buy a brand new Maple mini, and plug it into your PC or Mac or Linux box. Do not be suprised if you only see a DFU device. This is normal.

Just compile and upload a blank sketch.  Even a blank sketch will contain the Serial USB code, and your board should then appear as a “Maple Serial” device.

There is a common missconception that the STM32duino-bootloader, and the older Maple bootloader, contain both DFU (upload) USB support and also “Maple Serial” (USB Serial) functionality. However this is not the case.

Originally when Leaflabs wrote the Maple bootloader (back in around 2012) they tried to include both  DFU and Serial functionality, however they found issues with this under Windows. This is because the DFU and Serial functionality requires the use of 2 completely different (built in) drivers in Windows; when the Maple board is only one USB device.

Normally manufacturers create composite USB devices in this case, i.e one USB driver that performs both the DFU and Serial functions. But creation and certification of custom drivers for Windows is non-trivial and expensive. Hence LeafLabs chose to separate the DFU and Serial USB functionality, so that only the DFU driver is used when the bootloader is running and only the Serial driver is used when the Arduino sketch is running.

This method allows the use of 2 separate Windows drivers – both of which come as standard on all Windows installations.

Although the functionality of both DFU and USB Serial could have been included in the bootloader, it would make the bootloader and sketch core code (libmaple) more complicated, as the sketch would need to communicate with the bootloader in order to send and receive serial data.

So Leaflabs chose to go with the simpler option of the bootloader only containing the DFU functionality, and for the USB Serial to be compiled as part of the sketch. Although this is the simpler option, its probably the best one, because if the Serial USB support was contained in the bootloader, the amount of additional code to allow the sketch to send and receive Serial via the bootloader would make the overall size of the bootloader and sketch slightly larger.

Sketches do take slightly longer to upload than if they did not contain the USB Serial functionality, but uploads via DFU are generally faster than AVR Arduinos, so this isn’t a serious concern.

Another consequence of splitting the functionality, is that if the sketch crashes, then the USB Serial will also crash, and often the USB Serial device will not appear at all.

And… any board that has been freshly installed with a bootloader, will only appear as a DFU device, because the bootloader checks to see if a valid sketch is in the program (flash) memory, and if not the bootloader continues to stay in DFU mode until a valid sketch has been upload.

Making your own PCB prototypes without all the messing around with chemicals sounds like a dream come true. The availability of low cost and seemingly high precision engraving / milling machines could provide the ideal tool for this, but in practice things are not as simple or as good as they appear.

Ebay has a number of vendors selling desktop CNC mills, commonly called CNC3020. I think the 3020 refers to the size 30 x 20 cm. These are also often referred to as engraving machines, which is probably nearer to the truth than them being a milling machine. Prices start at around $600 (USD).

If you are thinking of buying one of these please read this whole posting, as there are various bits of important information, which I’ve inserted in what I think are logical places in the description of the unit and how its assembled, configured and used.

Models

The first thing to note with these machines, is at the time of writing there are two different variants available, the “old” and the “new” model.
The “new” / improved model has both different mechanics and different electronics to the “old” model.
This is an example of the “new” version.

The key difference in the mechanics seem to be a strengthened gantry on which the “spindle” / milling motor is mounted, with  a thick aluminum plate all the way across. I suspect there are other mechanical changes, but its hard to tell from the photos on eBay.

The other difference is the power supply / motor control unit. The “new” version seems to be housed in a black box, with a sloping front, where as the old version was in a blue box with vertical sides all the way around. The changes appear to be more than just the cosmetics of the box. The PCB’s in this box differ from the ones in the old model as well – however whether they are an improvement over the old version, or just an alternative set of boards, is hard to tell.

I’ve read a lot of postings about issues of the control unit “missing steps”. This is where the PC tells the control box to move the motor a certain number of steps, but the motor doesn’t turn as much as it is supposed to because the control unit has not passed the correct number of steps onto the motor. I’ve not personally experienced this issue, as it manifests itself with cutting head not moving as far as it should do in any particular direction. However I have found other issue where the cutting head was actually moving slightly too far. More on this later.

Assembly

My CNC 3020 arrived as a partial kit, but without a mechanical assembly manual. My unit came with a CD that contained some software and a word doc explaining in pigeon English how to configure the software, again… more on this later.

I suspect all these units arrive partially assembled, where the motors were not attached to the frame, and their control / power wires were not attached. However its a relatively simple process to attach the motors using the bolts that are supplied, and the unit even came with Hex / Allen keys to tighten up the bolts. You also need to fit the flexible couplers on between the spindle of the motors and the lead screws, but this also just involves doing up some small Hex screws.
One thing that was slightly odd about my CNC 3020 was that the 3 couplers were not the same design, but all had the same internal diameter for the motor and lead screw shafts. As the unit didn’t come with an assembly manual, I made a guess that the odd one out, of the couplers, should go on the main, back to front / Y axis lead screw motor, however I suspect it does not make any difference.

Once the motors are bolted on, and you guess which control / power cable goes to each motor, (you can work it out from which cable will nicely reach each motor), you can connect the 4 circular control / power cables to the back of the control unit, and connect the control unit to a PC via a Centronics printer cable.

Yes… This unit needs your PC to have a old fashioned Centronics / parallel printer port. If your PC does not have one, you are out of luck.

Buying a USB to Centronics adaptor cable will not work, as the software that is supplied with the unit directly generates square waves on the Centronic port’s pins, using a special Windows driver, and this will not work with a USB to Centronics adaptor.

Setup

Anyway, assuming you have an old PC, even a laptop which has a proper Centronics / parallel printer port, you should be OK; but please note, I am also using Windows XP, and I can’t comment on whether Windows 7, or Windows 8 etc, work even if you have a machine with the correct hardware.

The software that came on the CD with the unit, is “Mach3” except it is a “demo” / limited version, which seems to be quite old.

Once installed, you have to enter the calibration numbers as stated on any installation documents supplied with the unit. This is basically the number of steps that each motor needs to take to move the cutting head 1mm

The limitation of the software is that it will only process 1000 lines of GCODE data. GCODE being the standard language for CNC machines and is generated by all sorts of design packages.

The 1000 line limitation is something which is likely to be an issue for most users fairly soon after they start to try to mill anything other than some demo files e.g. the outline of the “Roadrunner” cartoon character, and the best option for most people is to buy the full / official version of Mach3, which at the time of writing, retails for $175 (USD).

There are other options, including using Linux to control the mill, and also to buy a dedicated USB to CNC adaptor – which replaces parts of the electronics in the control box; however I have not investigated these options as yet.

Once you have connected it all up, and calibrated the software, you should be able to move all 3 axis motors and do a test mill of the “Roadrunner” icon to confirm that everything is working OK.

Tip:  One thing I do to test a new set of GCODE is to set the Z  zero position of the unit to about 5cm above the actual milling bed, and without a cutter in the chuck, then run the GCODE without the spindle / cutter motor running.

Finally after quite some time you are getting slightly closer to being able to mill your own PCBs.   Generating the GCODE for the PCB is relatively simple. An open source package called PCB-GCODE (http://www.pcbgcode.org/ ) can convert either Gerber files to GCODE, or there is a User Language Program (ULP) for Cadsoft Eagle which will generate the GCODE “tap” files from within Eagle.

With the “etch” file loaded into Mach3, you can attempt to mill your first PCB, but first there are a few more hurdles to overcome

Securing the PCB to the milling bed

The main problem with milling a PCB is how to secure the PCB down onto the milling bed. As you will be drilling holes through the PCB as well as milling away the copper, you will need to mount something like a small sheet of wood onto the milling machine, and mount the PCB onto the wood. The best thing I’ve found so far to mount the PCB onto is MDF. The MDF needs to be thick enough so that the drill can completely penetrate the PCB and not drill into the aluminum bed of the mill. If you are careful, you can probably use 3mm or 5mm MDF, however these are likely to be too weak to attach to the bed using the bolts supplied with the machine, so I normally use 10mm or even 12mm MDF, as this feels really secure and robust. MDF has good dimensional stability as long as it doesn’t get wet or absorb a lot of moisture, but should work in most indoor environments unless you live somewhere very humid.

Initially I used masking tape to hold the PCB onto the MDF, however this doesn’t work particularly well, as the edges of the PCB soon start to lift off slightly, as most PCB I have appears to be not entirely flat.

If the PCB is not absolutely flat you will have major issues with the milling process. This is because the normal cutting head for milling PCB’s is a 20 deg or 30 deg V shaped engraving tool, hence the width of the section that is milled is dependent upon the depth that the point of the cutter is below the surface. So if your PCB lifts off by, for example 0.5mm, this is going to cause the cutter to penetrate into the board by an additional 0.5mm, which will mean it cuts a path which is approximately 0.25mm wider than you expect (assuming you are using 30 deg V cutter), this can be the difference between a track existing or getting milled away.

CNC with secured PCB

The way I hold the PCB in place is to clamp down at least 3 sides of the board using steel plates. I bought some steel fixing plates from a DIY store, which are about 15cm long by 3cm wide and about 4mm thick. I’m not entirely sure what use they have in building construction, but if you overlap them onto the edge of the PCB by a 5mm (or a bit less) them screw them down onto the MDF, the PCB is prevented from lifting on any of the sides. Of course if you have a PCB which bows up in the middle you will still have a problem, so you should try to use PCBs that are as flat as possible, and even possibly flatten them before hand by storing them flat under pressure e.g. between some heavy books.

I’ve seen some examples on the web, where people just used a small clamp in the middle of each side, and I think this would be equally effective; but either way its very important to clamp the PCB onto the MDF as flat as possible.

Cutting tool height adjustment

The next important thing is to set the exact height of the cutting tool. For a while I’d been using a sheet of paper as a feeler guage, and lowered the cutting head a little at a time, until it was in contact with a sheet of paper placed on top of the PCB, so that I could feel definite resistance, when trying to move the PCB, however this isn’t really accurate enough.

A better approach is to use the a continuity meter (buzzer / beeper) setting in a normal multimeter to determine when there is an electrical connection between the cutting head and the PCB. To do this I attach crocodile chips to the PCB clamps and to the cutting bit, and slowly jog the cutting head height down 0.01mm at a time until my meter beeps, I then raise the cutter a few 1/100 of a mm until it stops beeping, and I know its very very close to zero.

Even with the PCB clamped down, there can also be minor differences in its height, so its best to do this Z height calibration in the middle of the area you are about to mill. There is actually a program which will scan the PCB using this electrical connection and re-map the Z height of the milling to take account of minor fluctuations in the PCB thickness / height, however to use it you need to modify the control unit to accept the continuity as the Z zero limit, and so far in practice I have not found it necessary to go to this level of complexity.

Milling

When you have finally calibrated everything, you can start to mill the board, and hopefully you will not have too many problem with board thickness or warp.

After the “etch” path has been milled, you need to change your cutting bit to a 1mm or 0.9mm PCB drill, and load the “drill” tap GCODE file. Its important to not loose the X and Y calibration when you are changing the cutting bit for the drill bit, otherwise it will be very hard to get the machine re-positioned correctly to drill the holes in the correct locations.

I have attempted to use the same continuity technique to calibrate the Z zero on the drill, but I think perhaps the drills come pre-coated with some varnish, as they are not good conductors when they are new.

Its also very easy to snap the PCB drill, by applying downward pressure. So under no circumstances “jog” the drill down onto the PCB surface when its not spinning, otherwise you stand a very high chance of snapping it. Trust me, I have snapped one drill this way, and snapped a second drill trying to manually drill out some holes which the mill didn’t drill completely through a board.

As the depth of the drill holes isn’t that critical, as long as its completely through the PCB, its safer to use the paper technique, with some thicker paper, to get the Z height about right, even if its 0.5 or 1mm above the board, and set the drilling depth to 2,3 or even 4mm to ensure the drill goes completely though the PCB. (Assuming you have a decent thickness of MDF below the PCB).

After the board has been drilled, then and only then, should you release the clamps are remove the board.

Results so far…

So far I have only milled single sided boards. Milling double sided boards is technically possible, however I can see a number of possible problems around the re-registration of the zero point (X,Y), as after the board is flipped over, it would need to be repositioned to within about 0.05 of a mm in both X and Y of its original position. This can probably be achieved by adding a calibration drill hole at 0,0 in the board GCODE file. However the other problem is rotation. i.e 2 calibration holes would be needed to ensure the board is not slightly rotated. Or perhaps some sort of metal jig could be bolted to the MDF prior to milling the first side, to ensure that the board is refitted in exactly the same location.

I’m personally very skeptical about the feasibility of doing this. I know it can be done, but I think it would take quite a lot of practice and experimentation to develop a process to make reliable double sided PCB’s a practicality.

However overall, production of single sided prototype boards is entirely possible on the CNC 3020, it just takes some time and effort.

The world of the STM32 continues to get more interesting, with the recent availability of micro-controller boards based on the GigaDevices GD32F103. These devices have a quoted operating frequency of 108MHz, but as I will demonstrate, these boards also seem to work fine at 120Mhz.

I first became aware of a GD32F103C board being available on TaoBao.com, via a posting on www.stm32duino.com by @jackson009 about a month ago.

I did some research and discovered that GigaDevices have licensed the design of the STM32F103 from STM, and produced an enhanced version of the STM32F103.

(Update. Nov 18th 2015. When I published this article in September 2015, it appeared as if GigaDevices were a “strategic partner’ of STM. See http://www.eettaiwan.com/STATIC/PDF/201507/GigaDevice.pdf , however this has now been clarified by STM in a letter to Olimex, indicating that that STM have not licensed the STM32 core to Gigadevices

So it appears that the GD32 has been designed by Gigadevices to be pin and generally register compatible with the STM32)

The GD32F103 has a maximum quoted clock speed of 108MHz, rather than the 72Mhz on the STM32F103, they also have a number of other changes. However the main improvement seems to be the faster clock speeds.

I managed to get some GD32F103C8 boards from TaoBao, (via YoyBuy.com) about a week ago and set about trying to use them with the existing STM32 core.

Initial results were good. It was possible to flash the board using a USB to Serial adaptor, and the blink sketch worked OK, albeit it blinked faster than on the STM32. However Serial didnt work correctly because the clock rate of 108Mhz is 1.5 times faster than on the STM32, so I duplicated the STM32F1 core to make a GD32F103 core and set about investigating the clock settings in order to get the Serial and other timing related things working.

The first difference I noticed with these GD32F103 boards, is that the crystal is 12Mhz instead of the usual 8Mhz used on STM32 boards. Actually STM32 boards could use 12Mhz crystals but generally 8Mhz ones seem to be used on all STM32 boards I’ve seen on eBay and AliExpress.

The STM32 (and GD32) have a Phase Locked Loop (PLL) that multiplies the crystal oscillator frequency to become the master clock frequency. The crystal circuit is called the High Speed External oscillator or HSE for short. On the STM32 the normal setting for the PLL is to multiply the 8Mhz by 9 times to give 72Mhz, but as the crystal on the GD32 board is 12Mhz, the 9 times multipler gives 108Mhz – which is the maximum quoted operational speed of the GD32.

Looking at the other clock controls, the peripheral clocks APB1 and APB2 are quoted as being able to operate at 54MHz and 108Mhz respectively, so the prescalers (dividers) did not need to be changed for the board to operate at 108Mhz.

However at 108Mhz, the USB would not function. This is because the USB prescaler on the STM32 @ 72Mhz is set to 0x00 which gives a prescale value of 1.5 and hence a USB clock of the required 48MHz, and with the GD32 main clock at 108Mhz, the USB clock would be running at 72Mhz not the required 48Mhz.

On the STM32, there is just 1 binary bit to control the USB prescaler, with value of 1.5 x or 1 x, which means that the only clock frequencies that will allow USB operation (48Mhz clock) are 72Mhz and 48Mhz.

However on the GD32, there is an additional bit (23) so that there are 4 USB prescaler options, 1, 1.5, 2 and 2.5, which allows for higher clock speeds to be used while still allowing USB.

But… And its a bit but… If you do the maths,  to use the 108Mhz clock frequency, you need a USB prescaler value of 108/48 = 2.25,  But there isn’t a matching USB prescaler option

Which strikes me as being very odd.

The new USB prescaler values of 2.0 and 2.5 allow clock frequencies of 48 x 2 = 96Mhz or 48 x 2.5 = 120MHz.

I suspect that perhaps GigaDevices thought that they would be able to operate these devices at 120MHz and hence included a prescaler value of 2.5 to cater for this, but perhaps their production was yeild was not good for devices that could operate at 120Mhz over the spec’ed operating voltages and temperature range, so they had to fall back to saying the GD32 could operate at 108Mhz (and fail to point out that USB was not available at that frequency !)

But like most techie’s I’m always one to push the boundaries, so I thought I may as well set the main PLL to 10 and run the GD32 at 120Mhz and set the USB prescaler to 2.5 so that USB would have the correct clock.

The GD32’s I have, seem to run fine at 120Mhz, under normal domestic conditions, however initially the USB didn’t work.

On closer inspection, and after finding a circuit schematic on the web, it became obvious why the USB was not working: it was because the USB DP (D+) line was not pulled high via the normal 1.5k resistor, as the board does not have a resistor on either D+ or D-.  Where as most STM32 boards have 1.5k connected to D+.

So I fitted an external resistor, and the USB sprang into life.

I’ve now updated both the stm32duino-bootloader to include a generic-pc13 version which runs at 120Mhz and I’ve also updated the Arduino_STM32 repo to include a generic GD32F103C option. I’ve added a clock speed menu for the GD32, which allows selection of 72,96 or 120MHz, as these are the 3 values that allow USB to work. I could have included 48MHz, but I don’t see a need for this, apart from perhaps in low power applications. I’ve not currently included a 108Mhz option as USB doesnt run at 108Mhz and generally 120Mhz seems to work fine.

One note with the GD32 core. I understand from reading some docs translated from Chinese, that there are other changes e.g. changes to Timer Capture; but I have not made any changes to the core about this, because at the moment I’m not aware that the core uses timer capture. The only changes that probably need to be made to the EEPROM library and the bootloader, as there appear to be some changes to the flags that indicate when Flash has finished being erased, but at the moment the bootloader appears to work fine, so I will add that to my To Do list for future stability of the code.

(Update. Nov 18th 2015.

Since posting, this original article I have done some speed comparisons, and the improved clock frequency is not the only improvement. The Flash memory on the GD32 operates without any “wait states” (its known as “Zero wait state”). From what I recall, the STM32 requires 2 or 3 wait states at 72Mhz (don’t quote me on this, but I kown its not zero wait state).

This change gives an instance performance increase to the GD32 even running running at 72Mhz, which result in a Dhrystone test running with a Vax MIPS speed of 64.41 (@72Mhz) where as the STM32 was showing 48.81 – See this thread http://www.stm32duino.com/viewtopic.php?f=3&t=76&hilit=dhrystone&start=30#p5466

This is not a terribly scientific comparison, but I think gives a reasonably general indication of the performance differences between the G32 and the STM32

)

In conclusion, the GD32 is an interesting new addition for anyone interested in a cortex M3 device, especially as its very similar to the familiar STM32F103, or anyone interested in more performance than the STM32F103 currently offers.

This is the first in a series of posts about programming the Nordic Semiconductors nRF51822 Bluetooth low energy micro-controller using the Arduino IDE. The post is a big one as it describes the entire hardware and setup process.

The board I’m using can bought bought on eBay, AliExpress or Amazon for well under $10

The board does not have either USB or an onboard serial based bootloader, so at least initially, it has to be programmed using an external SWD programmer.

I’m currently using a Maple Mini STM32 board as a programmer

By programming it with a custom version of the Black Magic Probe firmware (more on this later), but any SWD compatible programmer should be able to program this device, as long as the programmer explicitly supports the nRF51822 – One other programmer which I know works is the JLink by Segger.

The Maple Mini is available mainly through eBay and AliExpress for around $5 (http://www.ebay.com/sch/i.html?_from=R40&_trksid=p2050601.m570.l1313.TR0.TRC0.H0.Xmaple+mini+stm32.TRS0&_nkw=maple+mini+stm32&_sacat=0 ) and you will also need a USB to serial converter to program it, like this one

http://www.ebay.com/sch/i.html?_odkw=usb+serial+cp2102&_osacat=0&_from=R40&_trksid=p2045573.m570.l1313.TR0.TRC0.H0.Xusb+serial+6+pin.TRS0&_nkw=usb+serial+6+pin&_sacat=0  or any USB to serial that supports 3.3V devices.

Although not essential, its a lot easier to connect the nRF51822 RF module if you use a “Motherboard” like this one, which are also available on eBay and AliExpress etc, for around $12 (USD) (without the radio module)

The main reason that you should consider buying this board, is that the RF module, uses pin size and spacing which is not commonly used on other development boards, i.e the pins are not 0.1 inch apart, and the pins are shorter and thinner than used on Arduino shields etc.

However if you are happy to solder some wires to the module, you can save yourself at least $10, which is what I’ve done as I’m still waiting for my Motherboard to arrive.

Anyway, enough of the hardware you’ll need…

What software is required.

The first thing you’ll need, if you don’t already have it, is a copy of the Arduino IDE. Currently the only versions of the IDE that I’m supporting are 1.6.4 and 1.6.5

Once you have installed the Arduino IDE you need to add either the Arduino Due or Arduino Zero board using the  Boards Manager. The reason this is currently required, is to install the ARM compiler and not for the actual Due or Zero. At a later date I will make a JSON file so that the nRF51822 can be installed without needing to install the Due, but at the moment this is the workaound you will need to use.

The next thing you need to do is download the third party core files from github https://github.com/rogerclarkmelbourne/nRF51822-Arduino/tree/S130_corelib, specifically this zip file https://codeload.github.com/rogerclarkmelbourne/nRF51822-Arduino/zip/S130_corelib

Next, go to your Arduino sketches folder and if there isn’t already a hardware folder, make a folder called hardware

Unzip it, and copy the RBL folder from inside /arduino-1.6.x/hardware into your newly created hardware folder, and restart the Arduino IDE

Now under the boards manager you will have a new board “Generic nRF51822”

Now to make yourself a SWD programmer from your Maple mini

First you will need to download the firmware from github https://raw.githubusercontent.com/rogerclarkmelbourne/blackmagic/master/binaries/blackmagic_maple_mini.bin

And also on Windows download the Flash Loader from STM http://www.st.com/st-web-ui/static/active/en/st_prod_software_internet/resource/technical/software/demo_and_example/stsw-mcu005.zip

Connect the USB Serial to the Maple mini by RX <–>TX and using GND and Vcc to GND and 3.3V on the USB to serial connector.

You also need to connect the Boot1 pin to gnd on the maple mini during programming

Then press and hold the button at the end of the Maple mini and then press and release the reset button (this will put it into serial upload mode)

Then use the STM Flash loader to upload the binary file to the Maple mini.

Once its been flashed, connect the Maple mini via its USB connector to your PC and it should be detected as 3 new USB devices.

On windows you will need to install the drivers for these, by downloading http://www.blacksphere.co.nz/downloads/bmp_driver_20130819.zip and unziping, then open the device manager and select each of the 3 unknown usb devices in turn and select update driver software, then browse to the folder you have just unziped and allow windows to install the drivers.

Note in the Windows device manager, which new USB device is shown as the GDB server, as you need to select that COM port number in the Arduino IDE to upload.

To connect the Maple mini to the nRF51822, you need to connect the following pins

For the SWD programming of the module use

Pin 6 -> SCLK on the nRF51822 or on the JTAG connector on the motherboard

Pin 7 -> SDO on the nRF51822 or on the JTAG connector on the motherboard

For USB to serial, you can use these pins on the Maple mini

Pin 8 -> P0.09

Pin 9 > P0.11

GND -> Gnd on the nRF51822 or Motherboard

You can use the USB to Serial that is on the Motherboard instead of the Maple mini, in which case don’t connect pins 8 and 9

If you are not using the motherboard or want to power everything from the Maple mini, you will also need to connect

Vdd to Vdd (either on the nRF51822 or the Motherboard)

Finally…

open an example sketch like Blink and upload, and if everything is working, you should see a LED blinking on the Motherboard.

If you won’t have a motherboard, you’ll need to connect a LED to pin P0.15, as this is currently the mapping that I’ve inherited from the RebBearLab files.

As regular readers will know, I’m a fan of the Nordic nRF51822 Bluetooth MCU, as it can be programmed developed using Open Source tools.

So when I saw the Dash Robotics Kamigami at Bay Area Maker Faire in May, and spoke to their hardware engineer Dwight Springthorpe, who confirmed that this innovative educational toy used the nRF51822, I took the plunge and bought one on the spot – at the special show price

See http://kamigamirobots.com/

Dwight told me that Dash Robotics were interested in people developing for this product using the Arduino IDE, so I hoped I could develop an Arduino library to allow the various peripherals of the Kamigami to be programmed by the Arduino IDE, or possibly develop using mbed.org

When I initially got in touch with Dash via email, they were reticent at providing me with any information about the hardware. So I set about reverse engineering the Kamigami.

Luckily a few days later I was able to get in touch with Dwight directly via email, and he has since provided me with some technical details.

As I first step I had to solder a 4 pin header to the empty header points on the board and hook it up to a SWD programmer and see if I could reprogram the nRF51822.

The connections are labeled on the silk screen,

GND = GND

CLK = SWCLK

3     = Vdd (3.3V)

D     = SWDIO

I hooked this up to a Jlink. (remember you need to connect the 3V pin to the Jlink or it won’t detect the nr51822 as being connected.

Before I overwrote the existing firmware, I thought it prudent to see if I could read back the existing firmware, in case I needed to re-install the existing firmware, while reverse engineering the hardware peripheral connections, and to my pleasant surprise I found that I was able to read out the all of the Flash memory, as the nRF51 had not been read protected.

So I now had firmware backed up in case I need to a restore.

At this point, I had intended to possibly poke around the PCB using a multi meter and a scope to try to determine how the peripherals are connected to the nRF51, but I suddenly realised that I could restore the firmware backup onto a more convenient debug platform, namely my WaveShare nRF51822 (http://www.waveshare.com/nrf51822-eval-kit.htm)

This board has a slightly different MCU, as it has the better QFAC variant with 32kb of RAM instead of the QFAA on the Kamigami but apart from that the MCU is identical. The other difference between the Kamigami PCB and the Waveshare is that the Kamigami doesn’t have the 32kHz RTC oscillator crystal (and the Waveshare does). This can make a big difference to the nRF51 startup code, and also its operation, because firmware written for boards with the 32kHz osc, don’t normally work on boards that omit this oscillator.

Fortunately the reverse is not generally true, and after flashing the firmware backup to the Waveshare board, I was able to connect to it using both Kamigami iOS app.

I selected the “Drive” option in the app, and twiddled the joystick that controls the 2 motors, and I noticed that some of the LED’s on the Waveshare board began to light up.

http://www.waveshare.com/img/devkit/accBoard/BLE400/BLE400-size.jpg

Specifically, the LED’s on pins P18,P19,and P20. All the pins seemed to be driven via PWM, as the LED intensity could be adjusted. P18 and P19 seem to get lit when the robot would be moving forward, and P20 was lit when the robot would be going backwards.

This seemed an odd arrangement, so I checked whether and of the other adjacent pins had PWM on it when moving the virtual joystick in the app, and found that P17 seemed to modulated when the robot would be going backwards.

i.e

P0.17 is left motor reverse control

P0.18 is the left motor forward control.

P0.19 is right motor forward control

P0.20 is right motor reverse

Hooking a scope up to these pins, revealed that they were modulated at a clock frequency of just 64Hz, and that the joystick control has slightly odd mapping, in that For Example, 100% PWM is delivered to the right motor, not when the joystick is fully forward in the middle, but is actually when the joystick is over hard to the middle left, when the robot is being commanded to turn left – not that this important information at the moment, but may come in handy later when programming some new firmware.

Incidentally, the motor driver IC’s appear to be GPY0067A, but I can’t track down a datasheet it… Not that this is particularly important as I’m pretty sure I know how to control the motors.

The next thing I looked for was what controlled the 3 tri-coloured LED’s (which are wired in parallel), and a quick visual inspection of the board, revealed that the LEDs were on pins P0.5, P0.6 and P0.7, and playing with the App isolated that

P0.5 = Blue channel

P0.6 = Green channel

P0.7 = Red channel

Looking at these on the scope was also interesting, as the App just seems to have each channel, either on or off, but the scope showed that the LED’s are actually being driven with 64Hz PWM (like the motors), so it would be possible to get the LED’s to be any colour from black to white, not just the 6 options in the “Games” section of the App.

Moving on to the inputs.

The ambient light detector seems to be attached to P0.02, as grounding this pin though a resistor changed the value displayed in the App.

The App displays the Battery level, but I have not been able to establish if this value is taken by reading the a pin, or whether its just a calculated value, which goes down depending on the amount of motor and LED usage.

The Kamigami also has a 6 axis IMU, with 3 accelerometers and 3 gyros. I was unable to read the markings on the IMU chip, so I emailed Dwight and he told me it is an ST LSM330.

I’m fairly sure that its connected via SPI, but I have not confirmed this with Dwight and I have not tried to communicate with it yet.

Its actually a real shame that Dash opted to use a IMU without a compass (magnetometer), as in my experience the outputs from the gyros and accelerometers are not especially useful, as they are subject to noise and drift which makes them useless for inertial navigation. Where as the magnetometer always lets you know which way up it is and where north is.(Assuming it has been correctly calibrated in the first place)

Developing using mbed

Although I have an Arduino core that works with the nRF51822, I know it doesn’t work unless the hardware has the 32kHz RTC crystal, and the Kamigami board doesn’t have this.

However there is an mbed platform for an nRF51822 module without 32kHz crystal –  for the HRM1017 (https://developer.mbed.org/platforms/mbed-HRM1017) , that can be used as an equivalent platform.

…

More to follow…

I’ve had quite a few comments where people are having problems uploading or running sketches on the nRF51822, so as I don’t have time to answer individual questions, I thought it best to try to cover the main reasons that things may not work

Device is not recognised by Blackmagic probe or possibly not by JLink

Originally I had a lot of issues with Blackmagic probe not recognising the ID code in the nRF51822. When this happens the Blackmagic probe reports the nRF51822 just as ARM cortex M0 rather than nRF51822

If you have this issue with my latest repo, please let me know, as the only option is to manually read the ID code and send it to me, so I can add that code to the list in the firmware and then rebuild the Blackmagic probe firmware.

The main problem is that Nordic do not keep an updated document of what ID codes they use, and most of the codes have been gathered and compilated by various users from various sources.

However I think this situation has now stabilized and Nordic have not released any new ID codes recently

This is not so much of an issue with JLink as you have to tell JLink which device you are programming,but this is not an option with the Blackmagic probe firmware.

nRF51822 chip is read protected / locked

This problem can occur if you are using a module which is pre-flashed with some firmware already.

In my case the  modules I bought from Wireless-tag (http://www.wireless-tag.com/index.php/product/9.html) , specifically http://www.wireless-tag.com/index.php/product/dis/25.html had this problem

I hoped the my JLink could disable the read protection, as this is a menu option in JFlash, however the option is greyed out and JFlash gives some erroneous error message when you connect, about an issue with the RAM

This problem can also be caused if you use JFlash to “Fill with zero”, as I found out by accident one day

Eventually I found a solution to this, on Nordic’s website https://devzone.nordicsemi.com/question/631/cannot-recover-with-nrfgo-could-not-read-ahb-ap-id-could-not-connect-to-target/

And the solution is to manually write commands into 3 of the nRF58122’s registers

In JLInk the commands are

w4 4001e504 2
w4 4001e50c 1
w4 4001e514 1

And GDB has an equivalent write command

After these registers are changed, it will cause the whole MCU to be erased and you should be able to connect via JFlash or Blackmagic probe without an errors and upload your new firmware

S130 softdevice has not been flashed into the bottom of flash (0x00000)

The bluetooth API functions provided by Nordic some in the form of a “Softdevice”

The best way I can describe a Sottdevice is a cross between a bootloader and a dynamic link library.

The code for all the BLE functions is in this closed source Softdevice, and the sketch makes calls into the Softdevice in order to access that functionalityAdditionally, the Sketch code is compiled to run at address 0x1c000 (for the V9 Soft device) – Note the latest version of the Softdevice, at the time of writing, is V2.0.1 from SDK V11, and is slightly smaller and expects the sketch (application) code to be at 0x1B000 – so make sure you download the old SDK V9 and use the S130 softdevice from that SDK.Basically the Softdevice is installed at address 0x00000 and when the MCU starts up, it runs a small amount of Softdevice initialisation code, and then the Softdevice passes control to the application sketch at 0x1B000, the Softdevice also attaches to some interrups to do its own functions, but all other iterrupts are forwarded to the application, as the softdevice inspects the applications (sketches), interrupts vector table and calculates the address to call inside the application code for each interrupt.Consequently unless you have installed the S130 softdevice into address 0x00000, the sketch will not run because it will be installed at 0x1C000 with jibberish in the flash at addresses 0x00000 to 0x1BFFF, which the MCU will run at startup.
I suppose if the flash from 0x00000 to 0x1BFFF was filled with nops this may work, but there are better ways of running without the softdevice e.g. change the linker script to position the sketch at 0x00000 and change the upload script to make sure its flashed at 0x00000Overall, just make sure the correct version of the Softdevice is flashed at 0x00000

Module does not have the 32Khz RealTime Clock crystal

If you installed the Softdevice and uploaded the sketch code and nothing works, e.g. including a “Blink” sketch, the reason is probably that your “no name” board does not have a 32Khz cystal oscillator

My current repo only works with modules that have the RTC.

I am working on an updated version that works without the RTC, but if you have a module that omitts this, you have 4 options

1. Solder a 32khz crystal and the 2 capacitors to the correct pins on your module (I did this with a Wireless-tag module)
2. Use Mbed instead of Arduino
3. Hack the latest version of the RedBearLabs Arduino repo to work with your board (this is what I’m now working on)
4. Wait for me to release my new version

Windows Blackmagic Probe driver problems

The BMP drivers work fine on Windows 7 but I have not tested them on Windows 8, or 8.1 or 10.

I have had a report that they may not work on W10 because of signing issues, which is strange as W7 requires signed drivers and they work fine.

If you have problems with driver signing on W10, just google for running unsigned drivers and there are some work-arounds, but its generally not recommended to run Windows permanently in a special mode to allow unsigned drivers, as it could be a security issue.

Other ways to work out whats going wrong

If you are not sure if you code is being uploaded, I’d recommend you powercycle your board and then reconnect and read back the flash from 0x1c0000 for about 1k and compare with the first 1k of the binary compiled by the Arduino IDE

If they are different, then you have not really uploaded, and with the Blackmagic probe this normally indicates that it has not recognised the MCU as a nRF51822 and is treating it as a normal ARM cortex M0 in which case I don’t think it can correctly erase the flash before programming it.

If you can’t connect via SWD, one cause can be transposed SCK and SDIO lines, so try swapping them over

JLink will not connect unless you feed 3.3V from the target board back into the “sense” input

With BMP its often best to manually run GDB and connect to the BMP and then connect to the nRF51822. See this post about connecting via GDB

https://github.com/blacksphere/blackmagic/wiki/Useful-GDB-commands

I’m afraid I do not have much free time to answer individual questions about installation or other problems, but feel free to post in case your questions or solutions help out others

Just a quick post about keeping the dust out of laser cutters

Australia is a very dry dusty country, and dust is a major problem for me with the laser cutter. If dust gets on the mirrors or lens, it gets heated up by the laser which then damages (spot burns) the mirror or lens

My machine, like most, has a large extractor fan in the rear of the machine, which sucks air out.

Air is drawn into the machine though any opening in the case, including the laser cabinet, but I saw no reason for air, and therefore dust, to be drawn though that part of the machine.

The simple and cheap solution is to buy household draft proofing strip from the local hardware store, and stick it where the door to the laser cabinet abuts the cabinet.

This worked best in the left of the picture, where the door presses directly into the foam strip.

It worked slightly less well at the top of the picture as the glue on this cheap draft excluder was not strong enough to prevent it being pushed downwards.

Nevertheless, it still provides a much better seal than there was before, and as you can see in this photo, there is no dust at all. And I promise I have not just cleaned it before taking the photo.

I have cleaned it, but not for months, as hardly any dust gets in.

When I bought by cheap “50W” Chinese laser cutter, I was alarmed to see that the brackets holding the laser in place were just bits of bent galvanized steel, packed around with a large amount of black rubber in order to get the laser into alignment.

And when I needed to remove the laser to clear some air bubbles that had formed in the cooling water, I found it virtually impossible to realign the laser into its original position.

My solution was to design some custom laser brackets which I could 3D print on my old MendleMax 3D printer.

The brackets fit a 2 inch diameter tube, with 2mm padding rubber used inside the bracket.

Height is adjustable, but was designed to work with my machine.

The design was done in OpenSCAD, however the code needs to be tidied up before I publish it, but I’m happy to share the STL file

Download by right clicking and saving the contents of this link laser_tube_bracket.stl

Note. You need to remove the .txt from the end of the file. I only added that additional (.txt) extension so that systems would download the file, as the .STL file extension is also used for security certificates and is sometimes blocked.

Just a quick post in case it helps anyone who has the same problem with their newly purchased Chinese laser cutter, where the menu language is set to Chinese (probably “Simplified Chinese”)

The original display looks like this. Note all the words are in Chinese

If you push the button labelled “Z/U” it opens the main menu, which is also in Chinese

If the machine has English set as the language, the menu would look like this.

So what you need to us press the down arrow, below the “Z/U” button, until the button at the top of the second column of buttons is selected.

This displays the language selection screen, where you need to select the third option down and press Enter.

If English was selected, the screen would look like this

Once English is selected, the text on the main screen will be in English and you can confirm this by pressing the “Z/U” button to enter the menu.

BTW, Pressing “Esc” exits the current menu.

PS. Someone else may well have already documented how to do this but I couldn’t find how to do this when I searched the web, so my method to figure out what was on the menu’s was to guess what words would be displayed e,g, “Language” and then use Google Translate to show be the Simplified Chinese equivalent, then visually compare what was on the menu with the Chinese characters, and fortunately they had called one of the menus “Language” so I was able to match the Chinese characters closely enough to work out which menu it was.

Annoyingly, inside the language menu, it doesn’t have the language names in latin text e.g. English or French or German etc.

So I had to google translate “English” to work out which language option

My Chinese laser cutter has a feature which allows it to be connected to a cabled LAN, but I’m always concerned about attaching random hardware to my home network as sometimes Internet connected devices have a “phone home” feature where they connect to a central server and send back log data, or possibly do other things which you’d rather they didn’t.

So although my workshop PC is around 5m from my laser cutter, I initially opted to use a USB extension cable to connect the PC to the laser cutter.

Unfortunately I found that using a long USB cable was problematic as the laser cutter kept disconnecting from the PC, and I’d have to unplug and reconnect the cable, almost every time I sent a job to the cutter.

As my workshop PC is not actually connected to the Internet, I decided it was safe to make a Ethernet crossover cable and connect the PC directly to the laser cutter via cat 5 cable. The cable worked well, and the connection does not drop out, and the cutter control software seems to work in exactly the same way as when communicating via USB.

As I was still curious about whether the cutter had a “phone home” feature, I decided to install WireShark on the PC and monitor the LAN traffic.

The control unit in the laser cutter is a RUIDA RDC6442G ( http://en.rd-acs.com/products.aspx?TypeId=50097&FId=t3:50097:3 )

On the control panel, you set the IP address of the laser cutter and also enter the address of a gateway, so I entered the IP of the workshop PC as the gateway IP, and then fired up Wireshark

I was pleased to see, that the laser cutter does not appear to communicate over the LAN at all, unless sent data from the control program (RDWorks) in the PC. I left the machine for several hours and not a single packet was detected.

This does not completely rule out that the laser cutter may attempt to communicate after an extended period e.g. every 24 hours, but at least it does not start trying to contact the Internet immediately

The control program RDWorks doesnt seem to access the Internet either, which is also very good news.

The main reason for monitoring the data was for network security reasons, but I had a quick look at the data protocol.

When RDWorks communicates with the cutter it uses UDP, sending to port 50200 on the cutter, and the cutter sends back UDP data to port 40200

The format seems to be proprietary binary, with RDWorks sending a command packet.

e.g. This seems to be the initial packet that is always sent by RDWorks

02:61:d4:89:0d:f7

to which the RDC6442G  responds with

c6

and then sends a reply packet e.g.

d4:09:0d:f7:8f:a1:09:c3:89

Another example is RDWorks sends

02:73:d4:89:89:8d

to which the RDC6442G  responds with

c6

and then sends

d4:09:89:8d:89:89:89:89:ab

When I sent drew a 10mm x 10mm square in RDWorks and sent this to the laser cutter, by pressing the start button, this appears to be the data for this cut (but at lest 5 commands were sent to the cutter before this data was sent, and RDWorks sent a further 411 bytes in the next command

f9:3e:d2:9b:fa:7a:8b:89:d2:89:70:8f:89:89:89:89:89:89:89:89:89:89:70:0b:89:89:89:89:89:89:89:89:89:89:70:0f:89:89:89:c7:99:89:89:89:c7:99:70:d9:89:89:89:89:89:89:89:89:89:89:70:59:89:89:89:c7:99:89:89:89:c7:99:70:8d:89:09:89:09:89:89:89:89:89:89:89:89:89:89:70:0d:89:42:8d:89:89:89:85:93:c9:d0:39:89:5b:91:d0:bb:89:5b:91:d0:49:89:af:bb:d0:cb:89:af:bb:d0:3d:89:af:bb:d0:bf:89:af:bb:d0:3f:89:af:bb:d0:b1:89:af:bb:c4:8f:89:89:89:89:89:89:c4:49:89:8b:70:db:89:89:89:89:89:89:89:89:89:89:89:70:5b:89:89:89:89:c7:99:89:89:89:c7:99:70:69:89:89:89:89:89:89:89:89:89:89:89:70:eb:89:89:89:89:c7:99:89:89:89:c7:99:c4:ab:89:70:dd:89:89:89:89:89:89:70:dd:09:89:89:89:89:89:70:5d:89:89:89:89:89:89:70:5d:09:89:89:89:89:89:7a:0b:89:89:89:89:89:89:89:89:89:89:7a:89:89:7a:09:89:fc:89:89:fc:09:89:fc:8b:0d:a3:31:95:49:8d:e3:1d:81:a9:fc:0b:89:89:89:89:89:89:89:89:89:89:fc:8d:89:89:89:c7:99:89:89:89:c7:99:fc:8f:89:89:89:89:89:89:89:89:89:89:fc:0f:89:fc:0d:89:09:89:09:77:77:77:39:f9:89:89:89:c7:99:e4:89:70:e9:89:70:1b:89:89:89:89:89:89:89:89:89:89:70:1f:89:89:89:c7:99:89:89:89:c7:99:70:2b:89:89:89:89:89:89:89:89:89:89:70:ad:89:70:81:89:09:89:09:77:77:77:39:f9:89:89:89:c7:99:c4:09:09:c4:8b:89:c4:09:b9:c4:09:99:c4:09:1b:42:8b:89:89:85:93:c9:d0:09:5b:91:d0:8b:5b:91:d0:0d:af:bb:d0:8f:af:bb:d0:0f:af:bb:d0:81:af:bb:d0:9b:89:89:89:89:89:d0:1b:89:89:89:89:89:c4:0b:05:82:89:89:89:89:89:89:89:89:09:9f:a2:89:89:89:c7:99:89:89:89:09:9f:04:09:9f:a2:89:89:89:89:89:89:89:89:8b:a5:04:09:9f:a2:89:89:89:c7:99:89:89:89:0b:cb:04:09:9f:a2:89:89:89:89:89:89:89:89:8d:d1:04:09:9f:a2:89:89:89:c7:99:89:89:89:0d:e7:04:09:9f:a2:89:89:89:89:89:89:89:89:0f:8d:04:09:9f:a2:89:89:89:c7:99:89:89:89:81:93:04:09:9f:a2:89:89:89:89:89:89:89:89:01:b9:04:09:9f:a2:89:89:89:c7:99:89:89:89:83:cf:04:09:9f:a2:89:89:89:89:89:89:89:89:03:d5:04:09:9f:a2:89:89:89:c7:99:89:89:89:85:fb:04:09:9f:a2:89:89:89:89:89:89:89:89:87:81:04:09:9f:a2:89:89:89:c7:99:89:89:89:07:97:04:09:9f:a2:89:89:89:89:89:89:89:89:99:bd:04:09:9f:a2:89:89:89:c7:99:89:89:89:19:c3:04:09:9f:a2:89:89:89:89:89:89:89:89:9b:e9:04:09:9f:a2:89:89:89:c7:99:89:89:89:1b:ff:04:09:9f:a2:89:89:89:89:89:89:89:89:1d:85:04:09:9f:a2:89:89:89:c7:99:89:89:89:9f:ab:04:09:9f:a2:89:89:89:89:89:89:89:89:1f:b1:04:09:9f:a2:89:89:89:c7:99:89:89:89:91:c7:04:09:9f:a2:89:89:89:89:89:89:89:89:11:ed:04:09:9f:a2:89:89:89:c7:99:89:89:89:93:f3:04:09:9f:a2:89:89:89:89:89:89:89:89:95:99:04:09:9f:a2:89:89:89:c7:99:89:89:89:15:af:04:09:9f:a2:89:89:89:89:89:89:89:89:97:b5:04:09:9f:a2:89:89:89:c7:99:89:89:89:17:db:04:09:9f:a2:89:89:89:89:89:89:89:89:a9:e1:04:09:9f:a2:89:89:89:c7:99:89:89:89:29:f7:04:09:9f:a2:89:89:89:89:89:89:89:89:2b:9d:04:09:9f:a2:89:89:89:c7:99:89:89:89:ad:a3:04:09:9f:a2:89:89:89:89:89:89:89:89:2d:c9:04:09:9f:a2:89:89:89:c7:99:89:89:89:af:df:04:09:9f:a2:89:89:89:89:89:89:89:89:2f:e5:04:09:9f:a2:89:89:89:c7:99:89:89:89:21:8b:04:09:9f:a2:89:89:89:89:89:89:89:89:a3:91:04:09:9f:a2:89:89:89:c7:99:89:89:89:23:a7:04:09:9f:a2:89:89:89:89:89:89:89:89:a5:cd:04:09:9f

I don’t think there is any point in further investigation of the actual protocol itself as RDWorks is free and although is Windows only, it appears to run OK under Wine on Linux.

Overall, although I would not connect the laser cutter to my internal LAN because of the safety implications of any computer on the LAN sending the command to start the laser cutter running, I think that from a network security standpoint it seems relatively safe.

If absolute network security is required a cheap wifi / wired router running OpenWRT or DDWRT could by placed between the laser cutter and the rest of the network to limit traffic to just UDP and ports and 40200 50200 and limit which IP addresses the laser cutter is allowed to communicate with.

Or just use a dedicated PC with no other network connections, like I do.

I recently bought a Mahoney laser power meter from “Bell Laser” (www.bell-laser.com , also known as www.2laser.com), to establish whether my “50W” Chinese laser cutter was actually producing anywhere near 50W.

The meter was on a special offer price of $95, reduced from $179 (USD), however its unclear whether this price is really always $99 and the $179 price is just to make you think you have getting a good deal.

Bell Laser have a video showing the meter in use here https://www.youtube.com/watch?v=Qhq122YiOwQ

Bell Laser list their address as Seattle, WA 98104 (USA), however this appears to be somewhat deceptive, as the online payment when buying the meter appears to be to a Chinese company (Na Tang, also know as Bing.tang), and the meter its self was shipped from directly from Hong Kong.

The time between buying the meter on the 2laser website and shipping was 8 days. It actually only took 3 days in transit as it was sent it by DHL, but I’m not entirely sure why it took 8 days just to send it out.

Packaging of the meter is strange. Its put inside a 4 inch diameter plastic drain pipe, which has ink jet printed label stuck completely around it.

The meter was wrapped in very dusty old bubble-wrap, but there was wasn’t enough bubble-wrap to hold it snugly inside the tube.
The ends of the pipe were capped with 2mm plywood disks which look like they were laser cut, and flimsy polystyrene sheet was stuck to the inside
The end caps are held loosely with tape, but both of mine had fallen off in transit and the meter was rattling around inside the tube.
The whole lot was wrapped in piece of corrugated cardboard which had loads of clear tape wrapped around it.

Overall, the packaging was disappointing, and although the plastic drain pipe stopped the meter being crushed, there wasn’t much to stop the meter rattling around inside the drain pipe, so its lucky it was not damaged in transit.

In terms of its operation its exactly the same as the Macken meter, as shown in this video https://youtu.be/DrbQdIAQl4s?t=70

The meter initially needs to have its reading zero’ed. This is done using a small spanner, (which is supplied with the meter), to turn a nut / screw on the back of the meter, which rotates the dial inside the meter.

You can only zero the meter, after the reading has settled as the meter temperature matches the current air temperature.

Once the meter has settled and has been zero’ed, you shine the unfocused laser on it for 37.7 seconds (this the time for my meter), and then wait for the reading to settle (for up to another 25 secs), before reading it.
Like all meters of this type, it is a “Calorimeter”, (https://en.wikipedia.org/wiki/Calorimeter)  made of a block of metal (in this case Aluminium) which has a known mass and known absorption of light at the wavelength generated by the CO2 or YAG laser.

When the laser light hits the calorimeter for a specific amount of time, it will heat proportional to the amount of power / energy being absorbed into the calorimeter.

Each meter is supposed to be calibrated in the factory, against a known standard, and the time the calorimeter needs to be heated in order for the gauge to read the correct value is engraved on the back of the meter.

In my case this time is 37.7 seconds. However I don’t actually have a way to know whether the meter has been accurately timed by Bell Laser,
But the whole point of paying $99 (Special offer price) for what is effectively a meat thermometer attached to a block of anodized aluminium, is that it is calibrated, as the cost of the components must cost less than $10.

The calorimeter block on my meter is 30.2mm x 10.2mm x 44.8mm. This size appears to be identical to the 200W meter sold by Bell Laser. But the 200W meter has a different scale plate fitted and has a much sorter exposure time (approx half of the time for the 100W meter). The 200W meter also costs $99 on special offer of $199 at full price, but this appears to be somewhat of a rip off, as its identical to the 100W meter apart from having a different scale dial on the meter.

As a matter of interests, I did a temperature / scale test, and the scale of my 100W meter seems to be 0.52 deg C per Watt.  I calculated this number by zero’ing the meter in cold water, and measured the temperature on a digital thermocouple thermometer (which read 9 deg C), I then poured in boiling water little by little until the meter read 100 W, and the temperature of the water was 61 deg C.

Hence a temperature rise of 52 deg C reads as 100W.
At the moment I only have the Mahoney meter so can’t double check these results, but my “50W” laser appears to output a maximum of 37W at the tube, and I get 32W after all 3 mirrors.
This is consistent with what other owners of the same laser cutter have reported and is consistent with the machine having a 40W tube rather than the advertised “50W” tube.

I will do a follow up post to this in the next couple of weeks, as I have bought a “DoHICKY” calorimeter from Russ of Sarbarmedia https://www.youtube.com/channel/UCqCyShJXqnElPTUnxX0mD5A

As the DoHICKY is calibrated against Russ’s “Macken” brand meter, so I will have something to compare my results to.

As a matter of interest, I thought I’d see if I could use the RDWorks laser cutter control program on Linux, even though its a WIndows only application.

Linux add-in called WINE ( https://www.winehq.org/ ) that allows Windows exe’s to be run under Linux.
However when I tried to install RDWorks using WINE I initially got a load of error messages which implied that loads of RDWorks DLL’s were missing or could not be located.

I initially thought this was because RDWorks had to run in a specific location, but after movingit to various places on my machine, I found the error messages were a red herring, and the problem was that WINE did not have one of the core Microsoft DLL files.

The fix for this was to install something called “Wine Tricks” https://wiki.winehq.org/Winetricks and use it to install the missing DLL.
MFC42.DLL

With this installed, The RDWorks installer will actually run and install RDWorks under Linux

However you do not install the USB driver, as the FT232 driver is already installed on most Linux installations.

Once installed RDWorks does run, but with one strange quirk; the vertical scaling in the design window is incorrect, and you initially get a bed shape that is very tall and narrow.

So I changed settings for page setting, and 900 x 400 looks good on screen. This setting isnt really important to the laser cutter its self, as its completely ignored even my RDWorks, as you can edit and cut objects outside of the bounds of the laser cutter (as defined in the setup)

One thing I have not managed to get working yet is the USB transfer to the laser cutter.
I think the issue is the mapping of the FT232 serial device on Linux to the COM port that RDWorks requires
The solution is probably that I need to map / link the systems’ serial port to the Wine serial port as described here
http://g8ogj.org/files/Using%20USB%20se … %20ipb.pdf

But I have not had time to test this yet.

An easier option is probably to transfer by LAN, as this works well under Windows and its likely to work on Linux.

As regular readers of my blog will know I’m an ardent fan of the Nordic nRF51 (and nRF52) series of Bluetooth Low Energy MCU’s.

So when I found out that a number of fitness tracker / smart watches, used the nRF51822 and could be easily opened and reprogrammed I was very interested and ordered 2 of them to try.

Unfortunately soon after I ordered them, it became clear that the model I had ordered would probably not be powered by an nRF51822, and hence started my quest to understand what models of smart watch do, really, use the nRF51.

Firstly, the model number of the watch I ordered was a TW64 – which is where the confusion starts.

A number of completely different watches are sold as a TW64 but contain completely different processors.

The ones I ordered, from eBay, had the Quintic QN9021 ( http://www.nxp.com/products/microcontrollers-and-processors/more-processors/application-specific-mcus-mpus/bluetooth-low-energy-ble/ultra-low-power-bluetooth-le-system-on-chip-solution:QN9021)  listed as the main processor, however when I opened mine up, it actually contains a Dialog DA 14850 processor  (http://www.dialog-semiconductor.com/products/connectivity/bluetooth-low-energy/smartbond-da14680)

Either way my watch unfortunately didn’t contain an nRF51

However searching for “TW64 nRF51822” does find some watches marketed as a TW64 which do contain the nRF51822, which lead me to Shenzhen DO Intelligent Technology Co., Ltd. on Alibaba.

I contacted them to find out more details and found that all of their smart watch/ fitness trackers use the nRF51822

Their product numbers are P101,P102,ID100HR,ID105,ID105HR,ID107,ID107HR,ID101HR,ID110HR,ID111HR and ID115HR

So if you are looking for an nRF51 based smart watch, your best bet is to search using one of those model numbers, and double check the details in the eBay / AliExpress / Gearbest etc listing to confirm it does mention the nRF51822

In the end I decided to buy an ID100HR and a ID107HR, via AliExpres.

When my ID100HR arrived, and I unscrewed the back of the case on the watch, I was pleasantly surprised to find that the watch contained an nRF51822QFAC, which is the 32k RAM version (top of the range for this MCU), and also that the watch has both the 16Mhz main crystal and also the 32kHz low power mode crystal.

With the help of Goran Mahovlic, I can now reprogram this watch using the Arduino IDE and can read from the accelerometer sensor, and write to the display, as well as get input from the button and turn on and off the vibration motor.

I have yet to investigate how the Silicon labs Si1142, Heart Rate sensor is interfaced to the MCU, but as its I2C, its possible its wired onto the same bus as the Kionix kx022-1020 accelerometer.

So it should be possible to use this feature of the watch as well.

If anyone wants to give this a try for themselves, please also read my previous postings about programming the nRF51822 using the Arduino IDE and also refer to my latest Arduino for nRF51822  repo on github.

https://github.com/rogerclarkmelbourne/Arduino_nrf51822

I know quiet a few readers of the blog are interested in the nRF51822, and use either the Blackmagic probe or OpenOCD to program your devices.

So I thought it worthwhile to share my experiences today, when I was unable to program a nRF51822QFAA device

To cut to the chase, the device identification in full is the nRF51822QFAAH1.  This appears to be a new revision of the QFAA device (16k RAM 256k flash), which neither the Blackmagic probe or OpenOCD support, as its CONFIG ID code seems to be 0x008F where as the QFAAH0 is 0x0072

I will endeavor to update my Blackmagic probe repo as soon as I have confirmation via the Nordic developers forum that this indeed the case.

I’ve also logged a issue on the master Blackmagic probe repo, and will bring this to the attention of the OpenOCD team if confirmed.

In reality, the problem of not being able to program a specific board, has taken a while to quantify, as I had a batch of 40 boards to flash with custom firmware, and the first board I tried seemed to have this issue, so I ended up using a Jlink to flash the boards (which had its own issues, but thats another story).

Anyway, of the 40 brand new boards I received from a Chinese manufacturer, only 1 seems to contain this new device, so it was sod’s law that it was the first board that I attempted to program.

And doubly confusing, as I presumed the whole batch had the new device, so I didnt take note of which board would not initially program, So ended up having to retest all 40 again to find it, and confirm that all the other boards contained the QFAAH0 version.

But thats the way the cookie crumbles some days.