DigisparkSync doen't work for long startup time

[DeqingSun]

I was testing this project with attiny13, it was strange that the reset command gave me this error:

Could not read back timings following transfer and sync command

After some debugging, I realized the fuse set of target AVR triggered this bug: I was using "Int. RC Osc. 9.6 MHz; Start-up time: 14 CK + 64 ms", the interval between reset command (0x07) and chip's signal+0x55 response was 79ms

When using "Int. RC Osc. 9.6 MHz; Start-up time: 14 CK + 4 ms", the interval between reset command (0x07) and chip's signal+0x55 response was 4.992ms. This time it works.

I guess the tinyUSB's wait time was too short. I haven't recompile the firmware but I think this might be the issue:

https://github.com/dcwbrown/dwire-debug/blob/d6af573913dd030b492ef3ae7d56bfd1f9226b65/usbtiny/main.c#L1309

[dcwbrown]

Thanks for debugging, I'm sure you're right.

The existing timing loops could be extended to allow for longer maximimum pulse widths, but this would reduce the resolution of pulse measrement and I think we need that to remain as it is in order to support the fastest clock speeds.

Since it is only the initial high to low transition that can be so long, maybe it makes sense to add code just for this scenario.

Here's a completely untested attempt:

;       Wait up to 190ms for dwire pin to go low

        ldi   r24,8           ; Number of approx 24ms periods to wait
        clr   r30
        clr   r31

dcw02:  sbis  0x16,5          ; 1/2. Skip if Pin PB5 set (mark, one)
        rjmp  dcw04           ; 2. dwire pin has gone low

        adiw  r30,1           ; 2.
        brcc  dcw02           ; 1/2. Continue waiting

        dec   r24             ; 1.
        brne  dcw02           ; Continue waiting

;       Dwire pin is still high after 190ms

        rjmp  dwc8            ; Exit with r24=0 (no readings)

;       Dwire pin has gone low. Enter timing loop waiting for next high

dcw04:  clr   r24
        clr   r30
        clr   r31
        rjmp  dwc6

This would go immediateley following the line you identified -

        cbi   0x17,5          ; Set DDRB 5 (reset/dwire) direction input            

Just putting this here so as not to forget - I'm not in a position to test it at the moment.

Feel free to try it out only if you want to waste time debugging my mistakes :-).

One concern is size - I remember memory being very short. I suspect a few bytes could be shaved off by significantly reordering this function, but that's a whole lot more work.

-- Dave.

[DeqingSun]

Hi Dave,

Thanks for your response. I'll fetch my Dragon and test it when I get my other projects finished.

By the way, I haven't spent much time in the speed issue. My logic analyzer shows there is 33ms between packages. Do you have any ideas where the delay happens? Is it a driver issue? or an Attiny performance issue, or something else?

Thanks Deqing

[dcwbrown]

I don't know offhand. The software USB implementation is very much on the edge of the USB spec and may be relying on the USB host retrying multiple times. It woud be interesting to know if you see the same 33ms when using an FT232 or similar.

By the way, many thanks for all your work supporting the Mac and VScode, very useful.

Cheers -- Dave.

[DeqingSun]

Hi Dave,

After fully understand this function I feel this bug may not worth fixing at this moment because I can change fuse of the target to avoid it.

The compiled code is 5898 Bytes, I'll see if I can put bootloader with the firmware.

[DeqingSun]

It seems micronucleus firmware takes 1596Bytes, which leaves 6522Bytes for the application. The memory is not short at all.

The bootloader eliminate the frequent use of High Voltage programmer.