avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #60863] avrftdi programming error probably caused by multiple, cons


From: Martin Thierer
Subject: [bug #60863] avrftdi programming error probably caused by multiple, consecutive empty pages
Date: Wed, 30 Jun 2021 14:41:29 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36

URL:
  <https://savannah.nongnu.org/bugs/?60863>

                 Summary: avrftdi programming error probably caused by
multiple, consecutive empty pages
                 Project: AVR Downloader/UploaDEr
            Submitted by: thierer
            Submitted on: Wed 30 Jun 2021 06:41:27 PM UTC
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Martin Thierer
        Originator Email: 
             Open/Closed: Open
                 Release: 6.3
         Discussion Lock: Any
     Programmer hardware: avrftdi
             Device type: m32u4

    _______________________________________________________

Details:

I get consistent programming errors when flashing the Arduino "Caterina"
bootloader
<https://github.com/arduino/ArduinoCore-avr/blob/master/bootloaders/caterina/Caterina-Leonardo.hex>
to an atmega32u4 with the avrftdi driver. The first 16 bytes of the bootloader
(at byte address 0x7000) are not programmed.

Flashing the same file with avrdude using either an usbasp or an usbtiny
programmer works fine.

This seems to be caused by the many empty (0xff filled) pages, which are only
guarded by a usleep(m->max_write_delay) in avrftdi_flash_write() because
polling doesn't work for them.

1. Using a delay instead of polling is what the datasheet suggests (28.8.1 /
4.) and the delay of 4.5ms is correct, so it's not obvious why it doesn't
work. My best guess is that libftdi or the chip itself buffer the data and
make ftdi_write_data() return while data is still transferred to the MCU,
causing the delay to start early. Increasing the delay 10x fixes the problem
for me, but I don't consider that the correct solution.

2. I wonder why empty pages are "programmed" in the first place? Even if the
flash wasn't erased I can't see that making a difference? Or does it? As a
proof of concept I modified avrftdi_flash_write() to skip empty pages (see
attached patch) and that fixes the problem for me, too.




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Wed 30 Jun 2021 06:41:27 PM UTC  Name: ftdi-skip-empty-pages.patch 
Size: 2KiB   By: thierer

<http://savannah.nongnu.org/bugs/download.php?file_id=51631>

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?60863>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]