PIC16F1454 used as inexpensive ARM debugger

in ARM, code, components, how-to, PIC by the machinegeek | 15 comments

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.

This entry was posted in ARM, code, components, how-to, PIC and tagged , , .

Comments

  1. hoeb says:

    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. ken says:

    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. Peter Lawrence says:

    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.

    • Hans de Jong says:

      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!

      • Peter Lawrence says:

        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.

      • Peter Lawrence says:

        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.

    • Some digging brought up the following document: https://github.com/x893/CMSIS-DAP/raw/master/CMSIS-DAP%20EULA.pdf

      The person posting that document is, I believe, doing it against the will of ARM and likely the contents of the whole CMSIS-DAP repo is probably not very legit with ARM. I take no responsibility for the source of the document, it simply came up from a Google search.

  4. Peter Lawrence says:

    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 :/…

  6. ken says:

    Ditto…what a stupid ARM tactic. This helps their ecosystem. Someone should gripe to them :-P

    • Peter Lawrence says:

      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. ;)

Leave a Comment

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

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