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;
    PORTD &= 0x0F;

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.

  • \$\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 acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.