Device descriptor read/64, error -71; no ISR?

[winterflood_j]

Hi all,

I am trying to port avrusbboot from http://www.fischl.de to the latest (2009-08-22) version of v-usb
I am using an atmega 328p at 20MHz, crystal oscillator (supported by the latest v-usb, but not the one in arvusbboot)

I am using the following circuit:
Vcc is 5V (3.3V is not enough for 20MHz)
1.5k pullup from D- to RESET, 1.5k pullup from there to Vcc (causes a reconnect when the programmer resets the chip or I push the reset button)
100ohm resistors on Dx to PortDx
3.3V Zeners (no 3.6V ones in the shop )
1M pulldown on D+ (for when the cable is unplugged)

D- goes to PortD0, D+ to PortD2/INT0

PORTD1,3 are debug LEDs, I turn on PORTD1 on entering the bootloader (before any usb setup), and the other one when leaving (test for the bootloader condition and boot sector use)

After some modifications, the code compiles
So far, the LEDs indicate I am entering the bootloader properly, but the device is not responding on usb:
dmesg says:
[284388.070538] usb 4-1: new low speed USB device using uhci_hcd and address 64
[284388.190169] usb 4-1: device descriptor read/64, error -71
[284388.413460] usb 4-1: device descriptor read/64, error -71
[284388.628777] usb 4-1: new low speed USB device using uhci_hcd and address 65
[284388.748406] usb 4-1: device descriptor read/64, error -71
[284388.971697] usb 4-1: device descriptor read/64, error -71
[284389.187012] usb 4-1: new low speed USB device using uhci_hcd and address 66
[284389.593728] usb 4-1: device not accepting address 66, error -71
[284389.705381] usb 4-1: new low speed USB device using uhci_hcd and address 67
[284390.112088] usb 4-1: device not accepting address 67, error -71

I saw this post:
viewtopic.php?f=8&t=2663#p11936
and therefore changed line 60 in usbdrvasm.S to:
# ifndef USB_INTR_VECTOR /* default to hardware interrupt INT0 */
# define USB_INTR_VECTOR INT0_vect
# endif
But to no avail

I suspected the ISR was not firing (based on aforementioned post and others), so I added these lines to usbavrdrvasm20.inc:
line 55>
;jo
ldi r16, 0xFF;
out PORTD, r16;
;/jo

I know this will clobber whatever might be in r16, screw up timing, and also activate D+/D- pullups, but at this point I don't care if it crashes completely, as long as it tells me the ISR is called...
This code might be very wrong, I'm new to avr assembly
The result was:
* Code size grew by 4 bytes (sounds right to me)
* The second LED on PortD does not turn on, even though the PC clearly toggles D- (I placed LEDs on Dx, and they shimmer on reconnect)
I tried without the Zeners, but no change (D+ is at 2.2V when only the pullup is driving it with the 3.3V Zeners, so maybe the level was too low to register as HIGH)
I tried connecting PortD2 to GND then Vcc manually after starting the circuit (should trigger a interrupt, no?), but the LED still does not turn on

This seems to indicate that the ISR is not called, any ideas as to why/where to look?

Thanks in advance,
Jonathan

[Grendel]

Bad Zeners would be my guess. For P type AVRs you really need 3.6V Z-diodes that are <= 500mW.

[Saimon]

It is not good idea to write code to asm source. Try to use another 1,5k pullup for D- data line(may be you AVR reset at d- level change).
Best regards, Saimon!

[winterflood_j]

Bad Zeners would be my guess. For P type AVRs you really need 3.6V Z-diodes that are <= 500mW.

Unfortunately the electronics shop here only had 3.3 and 3.9 Zeners maybe they can order others though (If i can explain that in Japanese...)
Indeed the effect of these is that the polarizing current is too low, resulting in 2.2V (with the 1.5k pull-up, I can't measure the voltage when driven by the PC as it's too fast for a multimeter), which might be too low to register on the AVR.

This is why I also tried with no Zener, and even manually (AVR should detect the input with no problem, even though communication might not work), but it seems that even then the ISR is not called.

It is not good idea to write code to asm source.

I fully understand editing the ASM source will probably kill the driver, but as soon as I know the ISR is firing, I will remove those lines.
Any other reason?

Try to use another 1,5k pull-up for D- data line(may be you AVR reset at d- level change).
Best regards, Saimon!

Indeed, I see that /RESET needs 0.9Vcc to guarantee a High value; my setup breaks this:
(Vcc---1.5K---/RESET----1.5K----D- ----15K----GND -> /RESET will be Vcc*0.916 when D- is on pulldown) (so the AVR can boot)
(Vcc---1.5K---/RESET----1.5K----D- ----GND -> /RESET will be Vcc*0.5 when D- is low) (so the AVR might reset)
I suppose a PNP or P-channel FET could be used to get this functionality, or using v-usb to drive the pull-up.

I thought of adding a bootup delay to see the reset, but that might make the AVR miss the USB initialization from the host unless I or v-usb drive the pullup only after the delay.
That said, Ubuntu seems to try initialization 4 times, So it might still work (I think I'll go with a delay and a driven pullup nonetheless)
I shall try again with separate pull-ups, and also add a boot-up delay, and keep you posted

Does v-usb automatically drive the pullup on init if it's defined in the config files, or do I need to explicitly connect?

Thanks for your help,
Jonathan

[Grendel]

After defining the ID resistor you need to explicitly connect it via usbDeviceConnect() .

[Grendel]

Wait a second -- 328p ? Did you see this ?

[winterflood_j]

After defining the ID resistor you need to explicitly connect it via usbDeviceConnect() .

Thanks

Wait a second -- 328p ? Did you see this ?

Yup:

I saw this post:
viewtopic.php?f=8&t=2663#p11936
and therefore changed line 60 in usbdrvasm.S to:
# ifndef USB_INTR_VECTOR /* default to hardware interrupt INT0 */
# define USB_INTR_VECTOR INT0_vect
# endif
But to no avail

This correction might not be right, which is why I posted it, but I think it is, based on the disassembly:

Code: Select all

[usbdvrasm20.inc:49]
USB_INTR_VECTOR:
;order of registers pushed: YL, SREG YH, [sofError], bitcnt, shift, x1, x2, x3, x4, cnt
    push    YL                  ;[-28] push only what is necessary to sync with edge ASAP
    in      YL, SREG            ;[-26]
    push    YL                  ;[-25]
    push    YH                  ;[-23]
    
;jo
   ldi r16, 0xFF;
   out PORTD, r16;
;/jo
;----------------------
[...]
waitForJ:
    inc     YL
    sbis    USBIN, USBMINUS
...

Code: Select all

00003800 <__vectors>:
    3800:   0c 94 61 1c    jmp   0x38c2   ; 0x38c2 <__ctors_end>
    3804:   0c 94 9c 1d    jmp   0x3b38   ; 0x3b38 <__vector_1>
    3808:   0c 94 7e 1c    jmp   0x38fc   ; 0x38fc <__bad_interrupt>
    380c:   0c 94 7e 1c    jmp   0x38fc   ; 0x38fc <__bad_interrupt>
[...]
00003b38 <__vector_1>:
    3b38:   cf 93          push   r28
    3b3a:   cf b7          in   r28, 0x3f   ; 63
    3b3c:   cf 93          push   r28
    3b3e:   df 93          push   r29
    3b40:   0f ef          ldi   r16, 0xFF   ; 255
    3b42:   0b b9          out   0x0b, r16   ; 11

00003b44 <waitForJ>:
    3b44:   c3 95          inc   r28
    3b46:   48 9b          sbis   0x09, 0   ; 9
....

I have setup my circuit to use a pull-up separately from /RESET, added a 4-second delay on boot (before usbDeviceConnect()) [had to compile it separately so I could use -O0 on the delay and -Os on the rest of vusb]
In this configuration, I get a delay on boot before anything happens, then the 'entering bootloader' LED lights, the PC detects the device, and that's it...
The 'entered interrrupt' LED does not turn on, and the AVR does not reboot (it cant, really, since D* are not at all connected to /RESET anymore)

Looks like I'm gonna have to write a test program to see if I can get INT0 to work at all separately of vusb.
Maybe the vector relocation used in the bootloader is broken somehow?

Code: Select all

int main(void) {
   delay_ms_20m(4000);
   
   /* initialize hardware */
   BOOTLOADER_INIT

   /* jump to application if jumper is set */
   if (!BOOTLOADER_CONDITION) {
      leaveBootloader();
   }

   MCUCR = (1 << IVCE);  /* enable change of interrupt vectors */
   MCUCR = (1 << IVSEL); /* move interrupts to boot flash section */

   usbInit();
   sei();
   usbDeviceConnect();
   for(;;){   /* main event loop */
     usbPoll();
   }
   return 0;
}

[Grendel]

Oops, skimmed right over that, sorry.

Very odd. I used the same BL w/ a mega8 w/o problems but later switched to bootloadHID since it doesn't need special kernel drivers.

Anyway, what are your fuse values ? You need to set the BOOTSZ bits to 1024 words (2kbytes), BOOTRST needs to be enabled. The loader text segment needs to be located at 0x3C00 (this is a word address !), starting w/ the vector table. W/ AVR Studio this would be set under Project->Configuration Option->Memory Settings. Add the entry: Memory type Flash, Name .text, Address 0x3C00. If you use a modified Makefile, the define BOOTLOADER_ADDRESS needs to be 7800.

[winterflood_j]

Anyway, what are your fuse values ? You need to set the BOOTSZ bits to 1024 words (2kbytes), BOOTRST needs to be enabled.

My flags are:
# http://www.engbedded.com/fusecalc/
#
#Features
# Ext. Full-swing Crystal, Ceramic resonator, BOD enabled, Start-up Time PWRDN/RESET 1K CK/14 CK + 0ms; [CKSEL=0110 SUT=10]
# Clock output on PORTB0; [CKOUT=0]
# Boot Reset vector Enabled (default address=$0000); [BOOTRST=0]
# Boot Flash section size=2048 words Boot start adress=$3800; [BOOTSZ=00]; default value
# Serial program downloading (SPI) enabled; [SPIEN=0]
#
# Low: 0XA6
# High: 0xD8
# Ext: 0xFC/04

And so I should use Word@$3800 ie. Byte@$7000 for the start of .text
My makefile was using Byte@$3800...
Fixing this turns on the 2nd LED indicating the atmega entered the ISR

Following this, I suspect that the atmega was originally doing this (it was erased before loading the bootloader):

Start at Word@$3800
execute NOPs until the end of pgm space and loop to $0000
execute NOPs until Byte@$3800 and start bootloader

on ISR, jump to Word@$3802
execute NOPs until the end of pgm space and loop to $0000
execute NOPs until Byte@$3800 and restart bootloader

My LED scheme was not detecting this since this is a "soft" reset, the LEDs were not turned off so the delay did not show; adding a line to turn them off before the delay corroborates this.

So the non-firing ISR problem is solved
However, the PC was still not happy.

I removed my two extra ASM lines, and it now connects OK:
[1550409.541237] usb 4-1: new low speed USB device using uhci_hcd and address 33
[1550409.712858] usb 4-1: configuration #1 chosen from 1 choice

This is with:
1.5K pullup on a separate line
100ohm resistors to the data lines
3.3V Zeners (will try 3.6V ones when I get them...)

On the particular PCs I have here, the Zeners are necessary

Now to try bootloading!

Thanks for your help
Jonathan

[Edit: I thought I needed the 2048 words bootload area, but turns out it's 1848 bytes including my fiddling, so I can probably go to 1024 words (I probably originally thought it was 1024 bytes)]