The u-blox-C027 is a complete starter kit that allows quick prototyping of a variety of applications for the Internet of Things. The application board has a MAX-M8Q GPS/GNSS receiver and …

Ublox might be a Ubrick !

13 Feb 2014

Hello to anyone trying out the new Ublox C027,

I've got 2 devices and I'm trying to find out how many people are having problems in just getting the normal 'Hello World' program to work and flash the LED. So anyone reading this please add your name and device you are using so that we may help each other out!

My Setup Scenario

  • I'm using an ASUS UX32 Laptop - running Linux Mint 13.
  • I have the Ublox C027-c20/u20/g35.
  • I'm using a Philips PZ1 ADP 64BB B with an output of 16v DC at 3.95 amps.

What Goes Wrong

When you connect the device it looks like a mass storage device as normal. You then flash the normal 'hello world' flashing LED binary via the browser to the mbed. The status light blinks fast - which indicates to me great somethings happening. This is where it goes wrong. The device vanishes as a mass storage device - then pops up again as if it was just inserted to the USB port. Once you open the mbed for browsing the file is not on the flash disk. However if you reset the device you will notice the LED blinks. So it seems the program IS on the device but not visible from the flash disk.

The next test i did was to add some lines to just print to the serial line so I know something is alive in there. I used cutecom as my app of choice to open a window to the ACM0 device. This is where it goes pear shaped! The device no longer responds to anything.

I've tried reset, reset with long press, removing power to power jack and usb then resetting. My program is below. DON'T USE THIS! It might brick your device..

ublox led flash and print line output

#include "mbed.h"
#include "C027.h"

#ifdef C027_REVA
 // on rev A we reasign the signal to A0
 #undef  LED
 #define LED A0
Serial pc(USBTX, USBRX);
DigitalOut myled(LED); 

int main() {
    pc.printf("C027 Ublox Test... \n\r");
    while(1) {
        myled = !myled;
        pc.printf("Changing LED Light ... \n\r");

I've made a youtube video of me trying this out.

Anyone got solutions or news on how to get this all working please let us all know!!!! :-)

Kind regards, Nicholas.

13 Feb 2014

Nicholas Herriot wrote:

The device vanishes as a mass storage device - then pops up again as if it was just inserted to the USB port.

This is the intended behavior. The CMSIS-DAP interface uses a virtual file system that programs the file into the target flash. The file doesn't exist on the interface file system.

If the flash programming fails there is a file that should appear on the drive named fail.txt with a description of what went wrong. If this file doesn't exist, the flash programming is assumed to have been successful.

Can you remove the printf statements and try to flash the LED's at a different rates? Let's see if you can get 4 or 5 different programming running on the device just flashing LED's without printf .

Also have you looked here for a firmware update to the CMSIS-DAP interface?

13 Feb 2014


on one of the devices it no longer looks like a mass storage device.

  • The UART light is active. Constant light.
  • The DPWT light is active. Constant light.

Typing />dmsg shows :

dmesg from bricked device

[   70.906202] usb 3-2: new full-speed USB device number 4 using xhci_hcd
[   70.929435] generic-usb 0003:0D28:0204.0002: hiddev0,hidraw1: USB HID v1.00 Device [MBED MBED CMSIS-DAP] on usb-0000:00:14.0-2/input3
[   70.929666] Initializing USB Mass Storage driver...
[   70.929769] scsi7 : usb-storage 3-2:1.0
[   70.930133] usbcore: registered new interface driver usb-storage
[   70.930136] USB Mass Storage support registered.
[   70.933802] cdc_acm 3-2:1.1: ttyACM0: USB ACM device
[   71.028095] usbcore: registered new interface driver cdc_acm
[   71.028098] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[   76.905735] [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 18070000, was 18000000

Any ideas how to get my device working again?

Kind regards, Nicholas.

13 Feb 2014

I forgot to mention.

The other device is working. I've changed the flashing light several times now.

A pointer on how to get debug i.e. printlines working?

Kind regards, Nicholas

14 Apr 2014

Nicholas -

I'm working with the c027-g35 on a Mac OSX and have had a very similar experience. I was able to download c027_supporttest to the c027 cleanly once but it's been bricked since then. The MBED device also will disappear from the machine in a manner similar to what you described on your Linux machine. I'm getting no printf output from the c027, but guessing from the LED behaviors, I think that the program is happily working. However, it's doing something that plays havoc with the Mac, and so I am no longer able to "drag and drop" anything to the mbed.

It seems that any future debug progress for me is dependent on figuring out how to erase whatever is in the LPC1168's flash right now. Do you have any clues for me on how to do that? Note that I've already updated to the most recent CMIS-DAP FW (v2.01,feb 28).

From comments on other threads, I take it you have figured out that the problem is related to behavior on the USB (i.e., any mbed program with a printf to the USB is not going to play well with the host machine). With my Mac OSX, I don't think I have an option to change any drivers. Is there anything that can be done on the MBED side (other than avoid using the USB as a serial port)?

Thanks for your comments so far - they've been helpful!

- Francis

15 Apr 2014

There is a patch for this problem that is currently being tested. Once that is complete the C027 downloading page should have the Mac and Linux compatible binary. Meanwhile, you should be able to develop on a Windows computer. Just wanted you to know a CMSIS-DAP fix was coming.

15 Apr 2014

Thank you Sam! I will look forward to the Mac patch. In the meantime, I need to figure out how to unbrick the c027. I found some suggestions here: Unfortunately, I haven't been able to get any of those techniques (ISP mode) to work for me yet. Do you have any other ideas for unbricking?

- Francis

15 Apr 2014

Hmmm…on second thought, if the fix is in CMSIS-DAP, I guess I don't really need to remove the existing code in the LPC1768; the new FW should fix whatever conflict now exists (no more brick!)…right?

15 Apr 2014

Right - and in the meanwhile if you have access to a Windows computer you can continue development until we release an update to CMSIS-DAP for this platform.

15 Apr 2014

Do you have an ETA for the CMSIS-DAP update? A rough approximation would be helpful: is it measured in days, weeks, or months?

For a guy who was born in Cupertino and first computer was an Apple IIe, asking me to work on a Windows machine is a little rough.

16 Apr 2014

Hi Francis,

sorry about the delay, I had to check on several machines before posting.

ARM have provided myself and Ashley Mills a binary firmware image. Today I just completed some testing on an ASUS Zenbook that has USB 3.0 ports.

All good for my I'm pleased to say.

Things to note.

With the new binary you ALWAYS need the power supply pluged in. So the device does not even pop up as USB MSD in dmesg unless you have the external power supply on.

There is a small dealy when you copy your new binary over and the device re-connects as a MSD. Longer than before I'd say.

The 'restart' works like a dream now. So ttyACM0 pops up every time I tried and I can talk to the device with cutecom with no problems over USB.

Suggestions ----

For your issue in getting round the brick. Does the device respond to doing the firmware upload? i.e. When you short out the pins and then insert USB, do you see the firmware binary when you open up your file manager? This is what I'd try, then upload the new binary using:

/> MAC dd if=mbed_if.bin of=/dev/disk* seek=4

Once I get a reply from the ARM guys I'll see if we can email you the binary.

Kind regards, Nicholas.

17 Apr 2014

Thanks Nicholas for the good report on the upcoming patch - I'm looking forward to the new CMSIS-DAP FW when it is ready for OSX (…in the mean time I'll look for a Windows machine to borrow). And yes, I am able to upload FW, so that's the first thing I'll try to get around the brick problem. (I've found these links very helpful:, The recently published c027_support library looks wonderful and I'm hoping to start using it soon.

14 Oct 2014

Regarding this quote from Sam, "The CMSIS-DAP interface uses a virtual file system that programs the file into the target flash. The file doesn't exist on the interface file system", does pressing reset automatically delete the bin file? I downloaded the helloworld program and pressed reset. Then I saw the LED1 flashing in the interval I set in the program but I could no longer see the program on the flash drive in windows filer explorer? Is this expected behavior? If it is, how would I delete a program from the flash?



14 Oct 2014

This is expected behavior. The file is "consumed" by the target flash and this flash is not exposed or readable over this MSD link.

18 May 2017

I tried to test Ublox C027 with blinking LED but once I compile and download the binary file .It vanish and can not see it on MBED and keep connect and disconnect and shows the message says : SELECT TO CHOOSE WHAT WOULD HAPPEN WITH REMOVAL DRIVE. The LED never flashed .

I am using WINDOWS 10