Maverick Embedded Technology Ltd.

Maverick Embedded Technology Ltd is pleased to announce a new addition to our product line-up.

“Maven” is a WiFi-enabled ARM Cortex-M hardware (SWD) debugger and programmer which, through its built-in GDB Server, interfaces directly with the Gnu debugger “GDB” over the local network. This means any host capable of running GDB can be used with Maven. There’s an onboard OLED display showing Maven and Target status plus rs232 output from the target. The latter is also available over the network via telnet.

Maven uses the same underlying hardware as our wAVR product, but with very different firmware and an additional “paddle” board which interfaces Maven’s 10-pin target connector with most of the standard ARM JTAG/SWD connectors. At the present time Maven natively supports nearly all devices in Microchip’s “SAM” range of ARM Cortex-M micro controllers, with support for devices from other manufacturers in the pipeline. No configuration files or third-party interface software are required; Maven auto-detects SoC parameters such as CPU core type, on-chip memory map and debug features (h/w break points anyone?). Maven also incorporates support for programming Flash memory on all supported SoCs, again without the need for configuration files on the host.

Paddle-board and cables:

Here’s a list of the standout features

• Built-in GDB server, accessible over WiFi, means you have full debug access to the target using the Gnu debugger GDB.
• Supports hardware breakpoints and watchpoints for debugging Flash-based firmware.
• Provides software breakpoints for firmware running from RAM.
• Can program Flash memory using GDB’s “load” command.
• Supports nearly all ARM Cortex-M “SAM” micro controllers from Microchip (Atmel).
• Support for Cortex-M micro controllers from other manufacturers is in the pipeline.
• Supports target voltages between 1.65 volts and 5.5 volts.
• Communicates with your target using RS232 on a UART or bit-banged I/O pin, making “printf” style debug very simple. Maven will make the UART data available over WiFi using the telnet command on your host. Both RxD and TxD are supported at all the common baud rates.
• Maven’s OLED display keeps you informed of both its status and various target parameters. It can also be configured to show the RS232 data received from the target.
• The USB interface provides two CDC-compatible RS232 interfaces. One of those provides access to the same target UART interface mentioned above. This might be useful if, for whatever reason, WiFi is unavailable. The other provides access to the ARM Cortex-M “SWO” serial debug output.
• All I/O signals between wAVR and your target are protected against electrostatic discharge, over-voltage and reverse voltage.
• In most cases, Maven can be powered by your target. Only when your target voltage is below around 3.1 volts will Maven need a separate power connection. Maven will show a message on the OLED display if its power-supply voltage is too low for reliable operation.
• Full galvanic isolation from your host PC and/or test/measurement tools when powered by the target.
• Firmware updates for Maven itself can be applied over WiFi. Note that Maven doesn’t phone home to implement this. It has a WiFi-capable bootloader which talks to a simple downloader program on the host.
• Included with the board are two ribbon cables (0.1″ and 0.05″) with IDC headers, and a transition “paddle” board for connecting Maven to the target ARM board. Note that a USB-A to USB-Mini-B cable is not supplied. The USB cable is normally only required to provide power to Maven if your target’s power supply doesn’t meet wAVR’s requirements.

The design files for a 3D-printable enclosure are freely available here.
The user guide for Maven is available here.

Maven is available to buy on our Tindie Store.

We’ve been busy over the last month or so developing firmware for wAVR which will turn it into a fully-fledged ARM Cortex-M programmer and debugger!

The ARM firmware recognises and supports all (we hope) Microchip SAM ARM Cortex-M micro controllers and there are plans to extend that support to include Cortex-M based micro controllers from other manufacturers. After that, the roadmap includes support for Cortex-A SoCs.

Using its built-in GDB server, you can connect GDB for ARM directly to wAVR using the “target extended-remote” command. No additional software is required. Most other USB-based debuggers require an additional program such as OpenOCD to act as the middle-man between GDB and the target. The new ARM firmware does away completely with the need for a middle-man. There are no fiddly configuration files; it works straight out the box with your SAM micro. GDB features like single-step, breakpoints (soft and hard), watchpoints, loading to Flash, etc, are all supported.

In future update we plan to add support for additional families of ARM micro controllers from other manufacturers such as the STM32 range from ST Microelectronics.

Right now development continues a-pace on the ARM firmware and it should be ready real soon now. Watch this space!

We are pleased to announce the availability of a firmware update which adds uPDI support to wAVR. In conjunction with the latest changes to avrdude with some additional patches, you can now program the new AtTiny devices which use the uPDI protocol.

Please check the downloads page for details.

After a week or so of coding, the firmware changes to support programming the latest range of ATTiny CPUs using the uPDI protocol are almost ready for prime time.

Also nearly ready is a patch for avrdude to add support for uPDI over jtagMKII.

There’s just one small remaining hurdle to overcome – the target’s fuses are proving troublesome to write – but I’m sure this will be sorted soon.

The good news is that uPDI support will be offered as a free firmware update to existing owners. If your uPDI target’s programming header conforms to the recommended 6-pin header pinout then wAVR should Just Work with the supplied ribbon cable.

As hinted at in the previous post, a firmware update for wAVR has now been released. This is a minor update which improves performance of the PDI (XMega) programmer – wAVR now supports PDI clock rates up to 10 MHz.

The update is available here. The MD5 hash of the ZIP file is:

MD5 (wAVR-1.0.1.zip) = 0a33a329329953680999ca60dd7078f6

Instructions for updating firmware are provided in the ReadMe.txt file included in the update. As usual, don’t hesitate to contact us if you have any problems updating your device.

So wAVR seems to be garnering some interest now and sales are beginning to pick up, which is great! Firmware development continues, although not much progress on ARM support as I’m undecided whether to go down the OpenOCD path or to do everything on-board. The latter will mean the firmware would need to have all the parameters for all the supported ARM CPUs “built-in”. Some more thought required I think.

In other news, prompted by a comment on AVR Freaks, I’ve been working on UPDI support. This is the one-wire interface/protocol used by the newest ATTiny range. The good news is that wAVR’s hardware can support it with just a firmware update. In addition, it’s given me a reason to revisit the low-level PDI physical layer code so that it can support both PDI and UPDI. The current firmware doesn’t cope well with PDI clock rates much above the default of 1MHz. However as part of the refactoring I’ve added DMA support for PDI data transfers. This allows wAVR to program XMega devices with PDI clock rates as high as 10MHz. The limiting factor, from a performance point of view, is now the turnaround time of the PDI line. Adding UPDI will require some patches to avrdude to extend its existing UPDI code so that it can be used via the jtagmkII (Dragon) protocol. I have this mostly done already.

I will likely back-port the PDI DMA support (minus the UPDI code sadly) into the currently shipping version 1.0 firmware over the next week or two so keep an eye out for news of an update!

wAVR is now for sale on Tindie, with worldwide shipping:

https://www.tindie.com/products/11366/

Numbers are limited at the moment, but if there’s sufficient demand then we’ll look into ramping up production.

Announced wAVR on AVR Freaks today. Must admit I was a bit apprehensive of the community’s response to Yet Another ISP Programmer, but it’s off to a decent start.

Clearly AVR is still a popular MCU but there’s no denying that ARM Cortex-M is encroaching into the traditional 8-bit micro space. wAVR itself was originally designed around an XMega MCU but was changed to a SAM4S4 when RAM became tight. Cost was also a factor; it beggars belief that a 32-bit MCU such as SAM4S4 is significantly cheaper than the 8-Bit XMega256A3U.

One of the design goals of wAVR was flexibility in terms of target CPU, to hedge against something knocking AVR off its perch. Obviously the initial offering is targeting AVR but the hardware should be more than capable of interfacing to the standard ARM CoreSight Serial Wire Debug (SWD) interface. It’s one, maybe two, pins short of being capable of a fully-fledged JTAG interface but SWD is well within reach.

So the next phase of the project is to add CMSIS-DAP support to wAVR, plus some simple patches to OpenOCD. I’m a little worried that it may not perform well due to packet RTT over WiFi, but time will tell.