Been looking at the circuit for the ATUSB

Werner Almesberger werner at
Fri Mar 25 19:24:27 EDT 2011

Richard Sharpe wrote:
> This weekend I want to try building a simple
> device driver that gives access to the ATMega registers via /sys/...
> as an initial version of the driver to give me some experience with
> it. The driver might also be useful for debugging other projects using
> the ATMega in that way ...

Do you mean transceiver registers ? The ATmega itself only acts as a
protocol converter (USB control transfers to register accesses with

Regarding the ATmega's firmware, this is where we are:

- I wrote my own very basic USB stack a while ago for the IDBG [1]
  project. This stack implements enumeration, vendor-specific control
  transfers, and bulk transfers. It was originally for the SiLab

  The stack also implements DFU.

- I later cleaned this stack up a bit, put it into the f32xbase
  project on qi-hw, and used it for the first atusb prototypes.
  All this is still around, under ben-wpan/atusb-sil/

  DFU invocation was automatic after reset, with a timeout. So if
  you wanted to flash new firmware, you would unplug and re-plug
  atusb, and quickly (< 2 s) issue the
  dfu-util -d 0x20b7:0x1540 -D atusb.bin

  If you don't need DFU, you just wait those 2 seconds, and the
  DFU boot loader will jump to the "application", which resets the
  USB stack, enumerates again, and then provides the USB-to-ATRF
  register/buffer access.

- after switching to the ATmega32U2, I reused my stack after
  generalizing and simplifying it a little (the interface between
  board-specific and general code was too convoluted in the older

  The new stack lives in atusb/fw/ and only supports the ATmega32U2.
  I plan to re-introduce support for the SiLabs chips at some point
  in time, though. (I'll mean to adapt the low-level driver, which
  should be easy; plus find a nice way to express the SDCC-specific
  compiler quirks, which won't be too hard either; and finally see
  how many SDCC compiler bugs I hit and work around them in a not
  too ugly way, which is what will be the fun part.)

- there is still a bug somewhere in the initialization that makes
  the Linux host reset the atusb board a number of times before it
  accepts its enumeration. Also, the stack only works if I let the
  ATmega do a full chip reset on USB bus reset. If I try to handle
  the bus reset via software, enumeration fails.

  These two bugs mean that DFU currently can't be used, because
  the chip gets reset when the application tries to restart the
  USB stack, thus jumping back into the DFU boot loader.

  Until this is fixed, the only way to change the firmware is with
  the atben-pgm cable and avrdude.

Regarding user space interfaces, sysfs access to the equivalent of
ben-wpan/tools/include/atrf.h could indeed be nice for debugging.
Ultimately, I think the driver will have to be able to reset the
transceiver if there's a communication problem, so it would have
to remember all the transceiver's configuration state.

The transceiver has "standard" state, e.g., channel selection, and
also non-standard state, e.g., selection of the Atmel-specific
high-speed mode (you can experiment with it with atrf-txrx's option

There's another user-space interface that would be useful to have,
and that's access to the Ben's 8:10 card pins via UIO. Right now,
I use mmap and hit the GPIO registers of the Jz4720 directly.
This is nice and simple, but it has the the drawback of not giving
access to interrupts.

UIO has interrupts. So it would be nice to have at least access to
this part. Whether UIO would be a good replacement for the rest of
the GPIO operations would depend on how much overhead it causes.

One problem to solve for atben is how to share the port with the
MMC/SD/SDIO driver. I'm not quite sure what's the best way to handle
this. For now, I just disable the MMC driver manually, with
echo jz4740-mmc.0 >/sys/bus/platform/drivers/jz4740-mmc/unbind

Port sharing is also an issue for any other non-MMC/SD/SDIO card we
plug into the 8:10 card slot, e.g., anything that uses UBB.

During development, we can just build the kernel without an MMC
driver, or with the driver(s) as module(s).

There's also a somewhat nasty issue with power: when the MMC driver
detects the presence of a card, it powers it up straight away and
then reads its configuration registers. This is okay for cards that
draw very little current when just talking to their configuration
part. MMC/SD/SDIO cards are like this.

Unfortunately, atben or things connected to UBB don't/may not have
such a low-power mode. In particular, bypass capacitors may cause
some significant inrush current. The result is that the Ben's 3.3 V
rail gets overloaded for a moment, causing the voltage to drop low
enough for the Ben to freeze.

The work-around for this issue is to drive all the 8:10 card pins
high for a moment before enabling VDD, which allows the capacitors
to pre-charge to a safe level.

My plan for now is to first build Lars' 2.6.38 kernel, see if it
behaves, then toss in the patches from linux-zigbee, add the
platform-specific tweaks, and see if anything works with atben
(such as detecing the presence of the card). Then push it all into
a ben-wpan branch on qi-hw/qi-kernel.git

I haven't used git for projects with multiple branches or multiple
committers yet, so please holler if I'm doing anything wrong.

Have you built a kernel for the Ben yet ? If not, maybe this is
useful (builds but I haven't tried to run it yet):

mknnk and nnui are from wernermisc/bin/


- Werner

More information about the discussion mailing list