PIC16F1454 used as inexpensive ARM debugger

dapper-usage
Peter Lawrence has been working on using a PIC as a CMSIS-DAP ARM debugger.

I wanted to see what was feasible in the way of a very-low-cost ARM board. OK, that doesn’t sound original, but stick with me.

The solutions that I’ve seen (Tweeny, McHck, mbed, etc.) are limited to wholesale firmware updates. Press a button, download a new image, and see if it works.

I wanted to implement an integrated CMSIS-DAP debugger (ARM standard that is compatible with multiple OSes). That way, one can do everything from flash updates to single-step debugging.

The brute-force solution would be to plop two ARMs on a board, where one has USB capability and acts as the debugger.

However, that gets pricey. Atmel, for example, is using an AVR32 on their Xplained boards in a debugger role to shave costs, but the AVR32 isn’t exactly a dirt cheap chip either.

Instead, what I did was use a PIC… a PIC16F1454 to be precise. It costs $1.25US in single quantity and goes below a US dollar in 1k+ quantity. Plus, it doesn’t need an oscillator (further lowering total BOM costs).

The firmware solution consists of two halves.

The first is a USB bootloader that also doubles as a USB-to-UART bridge (thereby also saving the cost of a FTDI chip or equivalent).

I’ve published the code (including patches to the Microchip USB Framework) here.

The bootloader lets one download an application into the second half of the PIC’s flash.

For a sample app, I’ve managed to write a CMSIS-DAP implementation that fits entirely in 4kwords of the PIC16F1454’s memory.

One of the ARM targets that I’ve tested it with is a NXP LPC812 (Cortex-M0+), which is a another <$1US CPU. So, with two $1 chips, a USB connector, an LDO, and some passives, one has a complete development board with integrated debugger. Plus, when the user is done with the debugger, a potential option is to download a new PIC app. For example, one might want the final use to be to emulate a HID joystick or keyboard.

For additional information visit Peter’s 2x4Logic website.

Via the contact form.

Join the Conversation

15 Comments

  1. Funny enough I am doing the same thing pretty much with the 16F1455 but with a the PIC32 as the target. Just got the low level primitives working for the programmer [debugger later.]

    Also looking to support other PIC families and maybe general purpose JTAG with openOCD.

  2. Really cool….wish he published a schematic/BOM as well so anyone can integrate it w/ an ARM design. It’s cost effective enough to just leave on a board…

  3. ken, yes, that was the goal of the project. Even if the PIC is just a serial bridge, it is cost-effective. A debugger would be a big bonus. As far as schematics, take a look at the conceptual schematic on the wiki page for the bootloader:

    https://code.google.com/p/pic16f1454-bootloader/wiki/Hardware

    The SWD interface in Dapper Miser is achieved with two of the PIC’s GPIO pins; any two could be chosen at compile time.

    The LPC812 is largely standalone and really only needs a decoupling cap (as it has its own internal RC clock).

    However, as I posted on the Hack-A-Day mention, the ARM EULA terms prevent public distribution of the Dapper Miser firmware. So, anyone can integrate the PIC as a serial bridge / USB interface / whatever for an ARM (or anything else), but the debugger isn’t freely distributable.

    1. What part of the debugger is not allowed to be released? Is the SW/DAP interfacing layer code? Or that you created an ARM debug/programmer tool with a non-ARM proccesor :-)
      Because I suspect one can just grab this and port it to any platform they want:

      http://www.lpcware.com/content/nxpfile/an11321-porting-cmsis-dap-debugger-cortex-m0-platform

      I have to say, implementing it on such a low level device is not as trivial.
      Sounds like a fun project to try out!

      1. AN11321 seems to be a thin veneer of documentation on top of the CMSIS-DAP deliverable. As such, the source code provided depends on a commercial USB library from Keil (an ARM acquisition). It is not a complete deliverable.

        The EULA is marked confidential (although it is ostensibly available to anyone who goes through the process of obtaining it), so it is not even practical to cite the content of the various clauses.

        Not using an ARM certainly runs afoul of one of the various conditions. This isn’t insurmountable; Atmel, for example, is using a AVR32 on their newer Xplained boards. However, Atmel has an ARM soldered on their PCB, thereby ensuring an ARM is on the target.

      2. Sorry… I’ve had to write too many ‘no I’m not give you my source code just because you think it is OK’ messages recently, and re-reading my response, I think this colored what I said.

        Thanks, and yes, learning the details of the protocol and figuring out how to write it efficiently was an interesting challenge.

  4. P.S.: the conceptual schematic is at 5V, but the LPC812 is a 3.3V part. The PIC16F1454 would need to be powered at 3.3V, not 5V, for interfacing to the LPC812.

  5. I wish ARM didn’t have those EULA terms about public distribution of code implementing the CMSIS-DAP stuff… I would love to see a line of low-cost open source debuggers. The FTDI based ones are ok, but those FTDI chips are expensive, you could sell these for pretty cheap. However, you would probably need to pay and ARM and a leg for the rights to sell your implementation of their debugger comms standard :/…

    1. I can sympathize with ARM; their products are easily pirated, and it is only the continual threat of serious legal action that keeps things in check. So, I think their lawyers probably default to acting in the extreme (out of necessity). However, to ARM’s credit, they do periodically adapt when they see a problem.
      A good case-in-point is the CMSIS deliverable EULA (support libraries and DSP routines). The initial license was quite onerous. However, to their credit, in April 2013 they re-issued under a more reasonable license.
      I’m less sympathetic with naming everything “CMSIS” something. ;)

      1. Not necessarily… Have a Open Workbench Logic Sniffer? A basic ARM will squeeze into its FPGA. FPGAs keep on getting cheaper and cheaper, and it is like having a chip factory of your own.

      2. Sure you can put an ARM in an FPGA, I have done it many times building prototypes to
        develop software on before tape out of the real chip. Except for that specific cases I don’t see much point. What you get is a slow ARM with limited memory in chip that is much more expensive than the real thing

Leave a comment

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.