USBaspLoader condition / BVZ55-C3V6

[mupf]

Hello!
My name is Michael and I'm working on a small project called the SNESoIP. It's basically an ethernet adapter for the Super Nintendo (SNES).
After a few considerations, I decided to produce a small batch of this device. With a few extras of course to make the end-users life a little bit easier.

I was thinking about the USBaspLoader. Now my questions:

- Could it work to use the USBs VCC to trigger the programming mode condition? I'm not using USB for power supply anyways. Here are my schematics: http://misc.mupfelofen.de/snesoip-rev2.pdf

and

- Because it would cause a few problems to make the whole circuit running at 3.3V, I've to use the (dirty) zener solution. But after all I've read I'm feeling a little bit insecure in choosing the right one. Could the BVZ55-C3V6 (5% tollerance) work? I also have a few 3.9V (TZMC-Series) in stock. All variants are SOD80 (Mini-melf).

Any help is highly appreciated!

Greetings
Michael

PS: Please be indulgent; english is not my native language.

[blargg]

You could have the USB Vcc connected (via a resistor perhaps) to an input pin that you poll or whatever in your normal program. If you detect that USB is connected, reset and run the bootloader. You could set the bootloader entry condition as a watchdog reset and then trigger that in your program.

Code: Select all

// bootloaderconfig.h
static inline void bootLoaderInit( void )
{
    if ( !(MCUCSR & (1 << WDRF) )
        leaveBootloader();
    MCUCSR = 0;
}

Though, I wonder whether you can just watch the USB data lines and somehow detect host connection. You'd have weak pull-ups enabled for both and watch for one going low, though I'm not sure whether that will actually occur. It'd avoid any extra pins for detecting USB.

[cpldcpu]

I think for reliable detection of the presence of a USB host you'd have to do this:

0) For enumeration
1) Wait for reset (long SE0). If reset times out, quit bootloader
2) After that, wait for n keepalive pulses (short SE0). If reset times out, quit bootloader

All of this will take at least 500ms if successull and longer of no host is present.

In my opinion it is better to rely on other methods to enter a bootloader.

[matrixstorm]

Please take a look at the revised USBaspLoader: https://github.com/baerwolf/USBaspLoader

In the current testing-branch: https://github.com/baerwolf/USBaspLoader/tree/testing
I included some features for removing the need of a bootloader-condition (i.e. a button or jumper)

* CONFIG_HAVE__BOOTLOADER_ALWAYSENTERPROGRAMMODE
* CONFIG_BOOTLOADER_LOOPCYCLES_TIMEOUT=16 & CONFIG_HAVE__BOOTLOADER_ABORTTIMEOUTONACT
* CONFIG_HAVE__BOOTLOADER_IGNOREPROGBUTTON

Thre you can configure (this eample):

Always enter the bootloader, but leave it automatically if no usbasp command was received within some timeout (16 cycles = a few seconds). Do not leave automatically if any command has received.
(Leaving bootloader means starting the firmware last programmed to the AVR)
Normally USBaspLoader would still be wathcing the PROGButton (condition) to also enter/leave bootloadermode depending of the state of the button.
However it is not necessary anymore and can be disbaled via "CONFIG_HAVE__BOOTLOADER_IGNOREPROGBUTTON".

BR Stephan

[blargg]

I think for reliable detection of the presence of a USB host you'd have to do this:

0) For enumeration
1) Wait for reset (long SE0). If reset times out, quit bootloader
2) After that, wait for n keepalive pulses (short SE0). If reset times out, quit bootloader

All of this will take at least 500ms if successull and longer of no host is present.

In my opinion it is better to rely on other methods to enter a bootloader.

I think mupf was suggesting using the USB positive power itself as a signal that USB is connected:

Could it work to use the USBs VCC to trigger the programming mode condition? I'm not using USB for power supply anyways.

This way the user just plugs it into USB and doesn't need to do anything else to begin PC communication. The code is likewise simple, just watching for the USB V+ line going high for a while, then running the bootloader. bootloaderCondition() could also be the USB V+ high, so the moment it's unplugged the bootloader exits.

[cpldcpu]

Oh, I agree, that could work. You'd need to activate the pull-up resistors because otherwise the zener diodes may pull the inputs low.