Dangerous Prototypes

I found by accident the Madelon development board (http://http://dangerousprototypes.com/docs/Madelon:_LPC_development_board) page in the project wiki.

Unfortunately, there seems to be nothing more than a PCB picture there... If I believe the logs, it looks like Lynn committed it back in October!

With its ARM Cortex M3 72 MHz CPU with built-in USB 2.0 device interface, such a board can be an interesting development platform.

The Madelon board looks a lot like Volt & Bytes's LPC1343 Breakout Board (http://http://voltsandbytes.com/lpc1343-breakout-board/) or Embedded Artists's LPC1343 QuickStart Board (http://http://www.embeddedartists.com/products/boards/lpc1343_qsb.php), though.

Does anybody knows if there is more information somewhere (schematic...)? I would be very interested to know the differences with the above boards.

In the meantime, here are a few suggestions I already mentioned regarding the V&B board:

• for better ESD protection, add a 10n/500V cap and a 1Mohm resistor between shield and ground, and a USB protection device across VBUS/D+/D- and GND, like the PRTR5V0U2X (http://http://www.nxp.com/documents/data_sheet/PRTR5V0U2X.pdf)
• for better EMI suppression on the USB, add a small ferrite bead on VBUS (BLM15HG601SN1D or equiv)
• add a BAT54C double diode to force RESET upon ISP, so you don’t have to hold both buttons down , and a 10K/100K voltage divider connected to USB_VBUS pin, so the LPC bootloader will automatically boot in USB mode if USB is connected, and to UART mode otherwise (cf. latest MicroBuilder design (http://http://www.microbuilder.eu/Projects/LPC1343ReferenceDesign.aspx))
• maybe change the LDO or have a dual footprint to accommodate for a smaller device, like the cheaper 150mA MIC5225 (http://http://www.micrel.com/_PDF/mic5225.pdf), which only requires small 2.2µF ceramic capacitors
• if possible, reorganize the 2×20 edge connectors by function (POWER, ADC, SPI, I2C, UART, GPIO1/2/3), rather than following the natural LPC pin layout
• ADDED: add a 0.05" pitch ISP connector

[quote author="Squonk"]
With its ARM Cortex M3 72 MHz CPU with built-in USB 2.0 device interface, such a board can be an interesting development platform.
[/quote]

Just FYI, it's full speed only (12 Mbps).

I like all your suggestions though.

Hi!

I have been studying the microbuilder board - and i find it easy and interesting at the same time, ide like to help make this board too - hows the development going?

[quote author="alanh"]Just FYI, it's full speed only (12 Mbps).[/quote]
Yes, it's a USB 2.0-compatible full speed device @ 12 Mbps full speed. Anyway, the high speed 480 Mbps is almost useless on a 72 MHz microcontroller.

What is nice in this microcontroller though, is that it has a built-in bootloader that will mount the chip as a mass-storage device, so flashing a firmware doesn't require any specific adapter...

And the DIP40 form-factor of this board makes it very interesting for breadboarding too.

Look also here (http://http://rossum.posterous.com/20131601) to see what you can do with this little but powerful CPU!

Thank you for the suggestions. The latest board files should be in SVN, but that is as far as we got with this one. There are so many of these out there it didn't seem smart for us to make another one.

Yeah, I know, but none of these boards have all the sophistication proposed above...

And despite the fact that the LPCXpresso is cheap and offers a built-in SWD link, it is still using a proprietary debug link protocol and thus ties you to their CodeRed Studio which has some irritating limitations in its free version (like no C++, grr...).

I was thinking of implementing an free/open serial (over USB CDC) SWD gdbserver, so if you have 2 of these boards, you can debug your project with the other one and using only completely free tools, such as Yagarto...

Here are 2 interesting links on the subject:

• http://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html
• http://blog.willdonnelly.net/2010/10/02/serial-wire-debugging-the-stm32-via-the-bus-pirate/

Maybe this will push you to reconsider any further developments on this board? It looks like Philip is also interested.

im doing the driver development on the microbuilder using the yagarto toolchain - only have one driver [not complete can only read write to an EEPROM :p]

[quote author="Squonk"]
Yes, it's a USB 2.0-compatible full speed device @ 12 Mbps full speed. Anyway, the high speed 480 Mbps is almost useless on a 72 MHz microcontroller.
[/quote]

Didn't say it wasn't.  Was just clarifying as most people read 2.0 = 480 Mbps.  And 480 Mbps is useful on a MCU if you are just moving data from point A to B with DMA - eg. via a FIFO, EMI, 4/8 bit SDIO, etc; if your controller has such interfaces.


[quote author="Squonk"]
I was thinking of implementing an free/open serial (over USB CDC) SWD gdbserver, so if you have 2 of these boards, you can debug your project with the other one and using only completely free tools, such as Yagarto...
[/quote]

Like st-link (http://https://github.com/texane/stlink)?  Using gdb under Linux to load code into RAM, run it with break/watch, and never touch flash is one of the main reasons I'm a new big fan of M3/M4s.

Not exactly st-link: I am planning to have the gdbserver into the "debugger" LPC1343 board in "remote serial" configuration for the upper side, and bit-banging SWD to the "application" LPC1343 board (or any other ARM Cortex board actually...) on the lower side. Please check the links above for clarification.

So all you have to do is just to configure the Eclipse CDT plugin to use a local virtual COM port (CDC ACM), instead of a remote TCP/IP port.

I may be wrong, but it looked like a clever idea to me... However, any comments are welcome!

I'm still trying to figure out the difference in st-link (real or a clone) verse what you are proposing.  Both speak a simple command protocol over a CDC/USB device bridge to access SWD.  It sounds like the only difference is yours would speak the GDB extended remote protocol verses needing a translator to go from that to ST's encapsulation protocol.  Sounds like it would only impact eclipse users and I'm still unsure why you couldn't just change the host software and not the device.  But sounds like you have it worked out.  g/l!

St-link is not using the USB CDC interface: v1 is using a (broken, see header in stlink-sg.c (http://https://github.com/texane/stlink/blob/master/src/stlink-sg.c)) mass-storage implementation, and v2 is just using raw USB thanks to libusb: see here (http://http://www.emcu.it/ST-LINKv2/ST-LINKv2.html).

Neither are supported under Linux, except for Will Donely's hack (http://http://blog.willdonnelly.net/2010/10/02/serial-wire-debugging-the-stm32-via-the-bus-pirate/) above using the Bus Pirate, and the reason why is that because the discovery’s stlink (both st8, st32) implementation of the USB protocol violates the USB standard in multiple ways and it's too much broken for the linux kernel driver (see here (http://http://comments.gmane.org/gmane.linux.usb.general/34815)).

This, and the fact that the gdbserver is always implemented in native/compiled C code makes it a pain to install a debug environment without having to compile stuff onto the host machine beforehand... Although this is true when using command line tools (which I also practice occasionally...), it is just more acute when running Java IDE tools like Eclispe + CDT plugin!

So a gdbserver/SWD proxy built into hardware makes a lot of sense, making the debug/flash tools really OS independent.

Both are supported under Linux.  I have a cross compiled arm-none-eabi-gdb taking to one right now.  Did you even look at my link above?  Yes you have to add some udev rules to prevent udev from automatically acting on the class.  It does work.

While I agree it would be less of a pita to build a extended remote target into a device, there are options today.  Though I would prefer your version since it's one less command I have to run.

Yes, you are right Alan, I forgot it: last time I checked the project, it was still in its early stage, it has gone a long way since then.

However, the "hardware" gdbserver/SWD approach would have another benefit: it would be vendor-independent, provided there is an middle abstraction layer for the chip specific mapping.

So it should also work with most Cortex CPUs, and maybe others CPUs too, by changing this middle chip abstraction layer and the backend (SWD, JTAG...).

On the host side, all you have to do is to install the toolchain (and maybe Eclipse+CDT if you want an IDE, but that's optional), without too much OS-specific hassle.

Kinda "hardware" OpenOCD, isn't it?

I like it.  Good luck.  Sounds like it would be a very useful tool for M3/M4 developers in general.  I would certainly buy a couple.

GUlp....i kinda lost track of the topic hehe, my experience with lpc is only up to SPI and I2C communications and building projects from those..

any simplier explanation of the discussion above?

Sorry, maybe we switched to a private conversation here, this wasn't intended.

Okay, let's summarize all that!

After finding the early PCB of an LPC1343-based board into the wiki, some improvements have been suggested (better ESD/EMI protection, smaller voltage regulators, an SWD debug connector...), still keeping the hacker-friendly DIP40 form factor.

Then we discussed the development of a debug/flash programming tools based on this board.

In former microcontroller, there used to be either vendor-specific debug/programming interface using the fewest possible number of wires, or JTAG-like interfaces for the largest microcontrollers having more pins available.

Then ARM Ltd. came out with the Cortex CPU core, which has been integrated into all the new SoC from NXP/ST/TI, etc.

Unfortunately, each vendor turned into proposing its own solution for debugging/programming using a vendor-specific serial in-circuit debug interface over USB.

What you should realize here, is that by this mean, they try to lock you to their product with their proprietary debug protocol, pushing you to use their (or their partner's) commercial dev tools... But this way, they also prevent free/open solutions from being used!

This is a shame, as the lowest-level SWD interface common to all these chips has been initially defined by ARM Ltd. and is (almost) standard over all these SoCs.

What is bad too on the host computer side, is that these proprietary tools require the installation of a vendor-specific piece of software to dialog with these vendor-specific hardware debug interfaces, using a gdbserver protocol "proxy" (frontend) in the case a GNU toolchain is used (a lot of vendor solutions are in fact GNU-based!).

So, the idea here was to integrate the gdbserver protocol (frontend) and the SWD low-level interface (backend) with just a thin software mapping layer in-between into the LPC1343 board, turning it into a vendor/OS-agnostic Cortex debug interface.

Moreover, if the low-level SWD backend can be replaced by a JTAG or any other vendor-specific backend, we have then an even more general microcontroller debug interface, requiring no software to interface with gdb.

Like Aln pointed out, this is very close to what st-link did for the ST products for the lowest part, just integrating the gdbserver protocol in it.

I am pretty sure there is more than that to do, but let's be optimistic!

I've built the microbuilder reference design. I really like it and hate it at the same moment. On one hand, the board could be much smaller and maybe etchable at home if pins weren't logically layed out, on another - i'm already designing a second "shield" for it, so maybe have main board this big allows you to make extensions for it without shortage of space.

Another thing i don't like with microbuilder is that they user parts that are hard to source. Why user sot-23 eeprom, when you have plenty space on board to use so-8 eeprom.

Regarding design by Dangerous prototypes - theres no diodes near programming button - that is really a nice feature to have, but it comes with a drawback - you need a voltage monitor, to hold reset for you while board boots. I've tried the board without voltage monitor (because again, it is one of those pin incompatible rare types) and it was entering into programming mode upon usb cable connection (without external power) until i've added voltage monitor. Tried to replace it with a cap, but nah, it either didn't work or worked buggy.

I'm gonna be ordering a PCB revision of microbuilders design with more widely available parts soon.

[quote author="miceuz"]Regarding design by Dangerous prototypes - theres no diodes near programming button - that is really a nice feature to have, but it comes with a drawback - you need a voltage monitor, to hold reset for you while board boots. I've tried the board without voltage monitor (because again, it is one of those pin incompatible rare types) and it was entering into programming mode upon usb cable connection (without external power) until i've added voltage monitor. Tried to replace it with a cap, but nah, it either didn't work or worked buggy.[/quote]
Now that I built an LPC1343 board with the same diodes as on the MicroBuilder board, I understand what you mean: without external power and thus supplying power from USB, when you connect the USB cable, the ISP signal is driven along with the RESET signal, thus causing the CPU to enter ISP mode.

I also tried to add a 100 nF cap across the RESET button: it looks like it is working the first time, but then it is random. So I guess you are right, I need to add a voltage monitor too.

Basically, my board is a 40-pin LPC1343 breakout board with 12 MHz crystal, USB Connect detection and disconnect, MicroBuilder's single-button ISP, ISP Header and the standard LPCXpresso user LED. I added proper USB ESD/EMC handling, all this on a 5x2 cm board. All parts where purchased at Digi-Key, but I am working on the BOM to be able to order the parts from other online distributors that are easier to work with in Europe (Farnell, RS...).

Here is what it looks like:
[attachment=0]
You can find the corresponding Sketchup 3D Model in the 3D Warehouse (http://http://sketchup.google.com/3dwarehouse/details?mid=144086a6a7cb82fd2ef54a87ac85e99d).

I plan to release the project as open hardware under CC-BY-SA license soon, as I just soldered the first prototype and that it is working as expected.

Let me know if you are interested in this design!

---

With regards to the voltage monitor requirement, in the past I've had good luck using a schmitt-triggered buffer and an RC-delay circuit to do power up-reset delays.  Nice thing is that single or dual package buffers come in SOT-23-6, SC-70, and SOIC-8 from just about every manufacturer.

After building a couple of projects on microbuilders design, i went another way - a quite big board that's expandable by arduino-like "shields" and that facilitates feature export to the case (like case mounted USB connector)

https://github.com/Miceuz/CatNip (https://github.com/Miceuz/CatNip)

I didn't build it yet though, waiting for seeedstudio

The USBug project is now available at https://github.com/Squonk42/USBug (https://github.com/Squonk42/USBug).

Here is a picture of the real prototype (not a rendering of the 3D model!!!):
[attachment=0]

---

Hi Sqounk, i have a little question about your USBUG schematic:

the BSS84-7-F (Q1) is a "P-Channel Enhancement mode field effect Transistor". So, i never used this kind of Mosfets before and i don't know anything about it.

long story short: can you explain me for what this type of MOSFET's is used for? or give me a few buzzwords? :)

thanks, the commandR

The BSS84-7-F (Q1) is just a basic P-MOSFET transistor, acting as an almost ideal switch for the USB LED and the 1k5 USB full-speed device enumeration pull-up resistor on D-. When turned on, Q1 will turn on the USB LED and connect the USBug to the USB bus. When turned off, Q1 turn off the USB LED and disconnect the USBug from the USB bus.

I initially planned to use a standard PNP BJT transistor (2N2097, BC857 or equivalent), but as it requires 2 additional resistors for polarization (1 in series with the base a few kohms, and the other across base and emitter, a few tens of kohms), I lazily swithced to a P-MOSFET which does not require any external component: used as an analog switch, the MOSFET channel has a low–on-resistance switch to pass analog signals when on, and a high impedance when off.

For a P-MOS, the source is the more positive side, and the more negative for an N-MOS.

thank you :)

i know that the 1k5 on D+ comes from the USB spec (1k5 on D- declares the devica as lowspeed, i think) and that the ARM toggle USB_CONNECT when it is ready to go (after init etc.).
I haven't seen PMOS the symbol with the diode before and thought it was a special kind of MOSFETS, this has kicked me out. but now i got it :D

I currently study your USBUG to learn how to handle ARMs with USB caps.

I hope i understood your schematic correctly:

"R3/R5 will cause the bootloader to boot into USB/MSC
mode if USB is connected, and into UART/ISP mode
otherwise."

so, this two resistors are pushing P0_3 to high, causing the chip to start USB enumeration. If the ISP button is pressed, the chip goes into the "firmware USB upload" mode.

I see: don't worry, there are a lot of different symbols for the MOSFET transistors: http://en.wikipedia.org/wiki/MOSFET#Circuit_symbols (http://en.wikipedia.org/wiki/MOSFET#Circuit_symbols). As I created the part in EagleCad, I took the right one for enhanced P-MOS, with the body-drain diode which is generally omitted (see "Why there is an inherent diode inside the MOSFET symbol? (http://http://www.edaboard.com/thread99177.html)" and IRF AN-1084 (http://http://www.irf.com/technical-info/appnotes/an-1084.pdf)).

Regarding R3/R5, they form a 1/10th voltage divider to protect the LPC1343's "USB_VBUS" input pin (PIO0_3, pin 14). Although this pin is 5V-tolerant and have a maximum rating of +5.5V and that the USB spec on VBUS is 5V +/- 5% (i.e. from 4.75V to 5.25V), it is not uncommon to see higher transient voltages during cable connection (up to 10V, see LTC3455/LTC3455-1 datasheet (http://http://cds.linear.com/docs/Datasheet/3455fc.pdf), figure 6 page 18). Practically, because of the 1µF/16V C2 capacitor and L1 used on +5V, it does not reach +6V. So although not strictly mandatory, the voltage divider is recommended!

And yes, if ISP is activated either by pressing the "ISP" button, or because the internal ROM does not see any valid application in Flash memory, the PIO0_3 (USB_VBUS) is checked to determine whether the UART or  USB interface will be used (see "LPC1311/13/42/43 User manual (v.4.0) (http://http://www.nxp.com/documents/user_manual/UM10375.pdf)", section 21.4 page 320 and figure 63 page 325).

However, this causes an issue when you plug in the USB cable when you have no external power supply: the USBug enters ISP mode unless you press the RESET button! This is because the RESET needs to be maintained low for a while after VCC is applied. I tried to add a capacitor to correct this, but it not reliable, as explained above. I am waiting for some MCP130T-315 (http://http://ww1.microchip.com/downloads/en/devicedoc/11184d.pdf) voltage supervisor parts that should do the trick.

Although simple, the schematic contains some other "finesses", like the ESD/EMC filters/protections around the USB connector, or the decoupling capacitors. I was thinking of adding a description into the GitHub project wiki...

Don't hesitate if you have any further questions!

A small update to let you know that replacing the R1 RESET pull-up by an MCP130T-135 (http://http://ww1.microchip.com/downloads/en/devicedoc/11184d.pdf) in SOT23-3 package fixed the problem with the USBug entering ISP mode upon USB cable insertion without external power supply.

So, I will probably include this mod into the next Rev. B board design. I may also include:

• change the P1 ISP header from R/A to vertical, as it is easier to find
• change J1 Hirose USB connector for one with standard post spacing, also easier to find
• change Y1 crystal for one that is easier to find
• change L1 footprint to 0603 vs. 0805
• disconnect J1 USB connector pin 4 (ID) from GND, as we are not OTG
• add a resetable fuse on VBUS

[attachment=0]

---

Hello squonk,

i was a little bit confused about the lpc1343 symbol in  your eagle lib. there is a JTAG port that i couldn't find in the datasheet.

Thank you for sharing your great project :)

Actually, the LPC1343 does not have a JTAG interface, but it features an SWD (Serial Wire Debug) interface as all ARM Cortex CPUs. The SWD appears only briefly at the top left of the chip block diagram in the datasheet. You have to read the comprehensive LPC1311/13/42/43 User manual (v.4.0) chapter 22 (http://http://www.nxp.com/documents/user_manual/UM10375.pdf) to find out more about this.

The SWD physical interface is using 3 signals at most (not counting GND):

• SWDCLK (SWD Clock)
• SWDIO (SWD I/O)
• optionally SWDO (SWD Output) for trace output

On the LPC1343 itself, these pins are multiplexed with other functions, and as there may be many functions on the same pin, symbol designers generally omit some as the string is getting to long...

On the debug connector, these pins can be shared with the standard JTAG signals as explained on ARM's website here (http://http://www.arm.com/products/system-ip/debug-trace/coresight-soc-components/serial-wire-debug.php).

If you are interested, more details on the SWD protocol itself can be found in this 3-part tutorial (http://http://www.lpcware.com/content/blog/introduction-cortex-serial-wire-debugging-part-one).