0
\$\begingroup\$

I built a small attiny85-based board using vusb and essentially the schematic of the discontinued Sparkfun "AVR Stick" (at least on the usb/uC side; see https://www.sparkfun.com/datasheets/Widgets/AVR-Stick-v12.pdf).

Trying to run micronucleus , a V-USB based bootloader, on it, I used the following config changes from the included tiny85-default example (to accomodate for different pins):

#define USB_CFG_DMINUS_BIT      0
#define USB_CFG_DPLUS_BIT       2
#define USB_INTR_VECTOR         PCINT2_vect

as far as i (and the available documentation) can tell, this is the correct setup.

when I try to connect it to my PC via usb though, I get enumeration errors, and attaching a logic analyzer to its VCC (to trigger on plugging it in) and data lines, I see the following traffic:

  • VCC high
  • a few random broken packets as the uC spins up
  • a loop of:
    • SYNC PID_SETUP 0x00 0x00 CRC_OK EOP (handshake begin)
    • SYNC DATA0 0x80 0x06 0x00 0x01 0x00 0x00 0x40 0x00 CRC_OK EOP (no clue)
    • expecting either a SYNC ACK or SYNC NAK packet now, but nothing happens, except for
    • a few evenly spaced (and very slow, compared to the previous packets) keepalives, until it retries this loop a few times (with a few resets+vcc cycles from my kernel trying to un-break the stuck device)
  • the data lines going into idle state as my kernel gives up on it and decides to just deliver power

I attached a csv dump from my logic analyzer here.

If anyone has an idea what's going on here or how to fix it (or at least how to get more info on what's actually wrong), any help is greatly appreciated :)

EDIT: forgot to mention above, the logic analyzer is attached at the uC pins, not inline of the USB connection, so it's very likely a software problem since the electrical signals definitely reach the uC. a simple pin-toggling test program (with unchanged fuses) confirms the uC is running at the time.

\$\endgroup\$
  • \$\begingroup\$ "and essentially the schematic" ... and what would be the "non-essential part" of your design? Why do you show a schematics for something else, and not for your own non-working design? \$\endgroup\$ – Ale..chenski Sep 1 '18 at 3:18
  • \$\begingroup\$ "DATA0 0x80 0x06 0x00 0x01 0x00 0x00 0x40 0x00 CRC_OK EOP (no clue)" - The host is trying to "GET_DESCRIPTOR" from your device, but your device is dead and not responding. \$\endgroup\$ – Ale..chenski Sep 1 '18 at 3:33
  • \$\begingroup\$ @Ale..chenski because the fact i replaced the white/yellow leds and NC at pins 2, 3 and 6 with a header doesn't matter, and the schematics for the "something else" that's equivalent are already online so i don't have to try and repaint or upload everything for no reason. the schematic i showed is the non-working part of my design, since a header with nothing plugged in doesn't matter electrically. \$\endgroup\$ – nonchip Sep 1 '18 at 7:52
  • \$\begingroup\$ @Ale..chenski ok, since the device does spin up fine when flashing it a simple pin-toggler/blinky/whatever-you-want-to-call-it, and the firmware was unmodified except for the 3 definitions to make it use the right pins; i suspect it might actually just not enter bootloader mode at all. the documentation actually mentions "it patches itself into the reset vector of the user program" which hints at me just missing the actual jump to it, since i don't have a "default user program" for it, literally just flashed the high range. \$\endgroup\$ – nonchip Sep 1 '18 at 8:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.