baerwolf / USBaspLoader

An (V)USB bootloader firmware for AVR-MCUs emulating the popular USBasp for programming itself
Other
178 stars 146 forks source link

A little more delay #8

Closed thomasfredericks closed 10 years ago

thomasfredericks commented 10 years ago

I am building a version with an atmega168 / 12 Mhz / 3.3V (I think this is out of specifications, but it seems to work for now).

I have a boot button instead of a boot jumper. With the USBaspLoader from Objective Development everything worked fine except I would get a warning about setting "sck" or something. So I decided to try this one.

With the latest USBaspLoader (20 November 2013) I could not get out of the bootloader. More precisely, even if I did not press my button, most of the time the bootloader would run and very rarely would the main code run. I suspected that the bootloader condition was checking before the button's pin had time to settle.

To solve this issue, I added the -DCONFIG_NO__NEED_WATCHDOG configuration to make some space. And then I added "_delay_ms(250);" just before the first "if(bootLoaderCondition())". The device now detects correctly if I a am pressing the boot button or not.

Is this ok? Is there another better solution?

zaidpirwani commented 10 years ago

I have been having the sort of same problem recently, but only some times...

baerwolf commented 10 years ago

Hi thomasfredericks, hi zaidpirwani.

Thank you for your report.

First of all, of course you can simply add some delay. Normally the pullup should be switched within 2 clock cycles. But maybe sometimes the capacitive load is too large and needs more time to charge up...

Until now, this was done by the unofficial patch-set of tinyUSBboard (http://matrixstorm.com/avr/tinyusbboard/bootloader/rev3_update_bootloader_v0x96x2.patch). "[PATCH 1/2] do some device wait before bootloadercond() to give pull-up some time to charge" In this patch you can use the "in-precise time-delay" to save some bytes...

If it is that a big issue, I am considering to put it into mainline.

However your issue also could be EMI related. Do you put 0.1uF between each Vcc and GND Pin ?

Perhaps you might also consider using recent commits from the "testing"-branch: Here you have new features allowing you to completely economize on the PROG button. ("BOOTLOADER_ALWAYSENTERPROGRAMMODE" + "BOOTLOADER_ABORTTIMEOUTONACT" + "BOOTLOADER_IGNOREPROGBUTTON ") You now also could control the bootloader from software...

BR Stephan

baerwolf commented 10 years ago

If no further comments are reported I'll close this issue as solved in 3 days.

thomasfredericks commented 10 years ago

"However your issue also could be EMI related. Do you put 0.1uF between each Vcc and GND Pin ?" Yes I do.

Hum, in my opinion this is not solved since I had to modify the current stable code for it to work.

About my design: I do not have a reset button, only a program button. I use all the pins for functions and the button is used for booting into the bootloader and is also used in the main code.

baerwolf commented 10 years ago

Hum, in my opinion this is not solved since I had to modify the current stable code for it to work.

Did you also try the testing branch - it contains most recent patches? But I see, so this issue stays open for now. If it doen't work with testing I will provide a patch for mainline.

Independent from this issue you may try out the new features from testing, which will allow you to also save the PROG button.

Hope to read from you soon.

BR Stephan

baerwolf commented 10 years ago

Okay everyone.

Please test https://github.com/baerwolf/USBaspLoader/commit/94c580cc75aaac3ebd6a061953386b6c83a46fe9 as part of the new testing-head.

Please acknowledge so I can close this issue.

Thanks and BR Stephan

thomasfredericks commented 10 years ago

Hi, I tried compiling this morning.

I changed the following in Makefile.inc to adapt it with my board:

F_CPU = 12000000
DEVICE = atmega168
DEFINES += -DUSB_CFG_DMINUS_BIT=4 -DJUMPER_BIT=3

I also use different fuse settings (brown out voltage), so I also changed FUSEOPT_88 to:

FUSEOPT_88              = -U lfuse:w:0xf7:m -U hfuse:w:0xd6:m -U efuse:w:0x00:m

But when I try to compile with "make firmware" I get the following message:

======>BUILDING BOOTLOADER FIRMWARE
.
make[1]: Entering directory `.../firmware'
      0 [main] sh 3696 sync_with_child: child 708(0x21C) died before initialization with status code
 0xC0000142
    450 [main] sh 3696 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
make[1]: *** [main.asm] Error 128
make[1]: Leaving directory `.../firmware'
make: *** [do_firmware] Error 2
baerwolf commented 10 years ago

Hi thomas

If this issue isn't related to delays, please open/create another issue. However your problem seems be caused by your toolchain. I took your configuration and I could compile. (I attach testing-branch, but it also works on most recent release.)

I used official Atmel toolchain 3.4.2 (http://matrixstorm.com/avr/files/avr8-gnu-toolchain-3.4.2.939-linux.any.x86_64.tar.lzma).

Please be also warned: You can not simply change the BrownOut threshold, since your ATmega168 needs at least 4.5 V to operate on the necessary clockspeed.

Precompiles stuff for you: http://matrixstorm.com/baerwolf/files/tmp/i-23042643-23ffa3a6d1db12ab73d0fce18542efc1fe68ef3b-1092625.zip

thomasfredericks commented 10 years ago

Hi, I uploaded the precompiled and it works fine. Thanks.

Please be also warned: You can not simply change the BrownOut threshold, since your ATmega168 needs at least 4.5 V to operate on the necessary clockspeed.

I know this is out of specs, but my design runs on a li-po battery and has been fine up to now.

If this issue isn't related to delays, please open/create another issue.

Will do. Thank you once more.

baerwolf commented 10 years ago

Can I close this issue?

thomasfredericks commented 10 years ago

Yes.

baerwolf commented 10 years ago

Okay, thank you all for the nice discussion - closing issue as solved.