0
\$\begingroup\$

When I program my AT90USBKEY2 with dfu-programmer, the delays are wrong until I restart the board by unplugging it.

#include <avr/io.h>
#include <util/delay.h>

int main(void) {
  DDRD = 0xF0;
  while(1) {
    PORTD |= 0xF0;
    _delay_ms(100);
    PORTD &= 0x0F;
    _delay_ms(100);
  }
}

A simple program. F_CPU is defined in the makefile.

Makefile I am not proud of does these steps:

avr-gcc -Wall -Os -DF_CPU=1000000 -mmcu=at90usb1287 -c blink.c -o blink.o
avr-gcc -Wall -Os -DF_CPU=1000000 -mmcu=at90usb1287 -o blink.elf blink.o
avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
dfu-programmer at90usb1287 erase
dfu-programmer at90usb1287 flash blink.hex
dfu-programmer at90usb1287 reset

Reading pin 6 of port D shows this: 15.6 ms high, 63.0 low 15.6 ms high, 63.2 low.

After bouncing power, and any time it's started after that 100ms square wave 100ms high and low, the correct timing.

I also tried a pin on port A that isn't tied to an onboard LED, same results.

avrdude: safemode: Fuses OK (E:F3, H:99, L:5E)

AVR Fuse Calculator

Am I doing something clearly wrong, or is it just accepted that I have to unplug the board after programming?


It seems like this might just be an issue where the reset button/dfu-programmer reset doesn't reset it properly. I don't know how that works yet, will update when I learn more.

Though bouncing the thing after programming isn't the worst.

\$\endgroup\$
  • \$\begingroup\$ What exactly is your question? What is supposed to happen that is not? Give us something to go by. \$\endgroup\$ – Sparky256 Mar 13 '18 at 4:57
  • \$\begingroup\$ @Sparky256 The question is "do I have to unplug the board after every programming", sorry about the poor phrasing. Reworded in the question. \$\endgroup\$ – mtfurlan Mar 13 '18 at 5:18
  • \$\begingroup\$ So after programming you get 15/63ms and after unplugging power just once, it changes to "exactly" 100ms high/low pulses? \$\endgroup\$ – Rev1.0 Mar 13 '18 at 8:13
  • \$\begingroup\$ @Rev1.0 So it was exactly 800 when I put it on a scope, but I didn't realize the clock divider was on by default, I was so focused on the first issue with the non-equal ratios and thought any other weird timing must be related. So when I fixed my F_CPU and timed it with a stopwatch(with increased time) it was roughly right. I'll measure it again tonight just to be sure. \$\endgroup\$ – mtfurlan Mar 13 '18 at 13:46

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.