Posted on

Improved Maven/wAVR available on Tindie again

After a 12-month hiatus (self-imposed due to other work commitments) we’re pleased to announce that Maven and wAVR are back in stock on Tindie, with some great firmware improvements:

  • In addition to improved support for existing Microchip/Atmel SAM devices, Maven now supports many STM32F1 and STM32F4 parts from ST Micro. For example, the STM32F103C8T8 found on various “Blue Pill” and “Black Pill” stm32duino boards is fully supported.
  • Maven’s GDB server has been enhanced to interoperate reliably with more IDEs, including Eclipse, and IAR’s Embedded Workbench for ARM.
  • ARM semi-hosting is now supported – you can redirect semi-hosted console I/O to Maven’s terminal server. This could be very useful on targets with no spare UART ports.
  • Both wAVR and Maven have a screensaver to protect the OLED display from screen burn.
  • Many other bug fixes and stability enhancements.

New devices will ship with firmware 1.3 from today. Existing customers can download 1.3 update images for wAVR here, and Maven here.

Posted on

Introducing Maven – Full-featured WiFi-enabled Programmer/Debugger for ARM Cortex-M CPUs

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.

Posted on

ARM Cortex support coming soon

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!

Posted on

uPDI Support Almost Ready

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.

Posted on

Firmware update 1.0.1

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.

Posted on

Maybe some firmware updates coming soon

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!

Posted on Leave a comment

wAVR is live! Where to next?

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.