bugAVR Downloader/UploaDEr - Bugs: bug #52653, device initialization often fails...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #52653: device initialization often fails in FT232R syncbb mode, due to glitchy start sequence

Submitter:  Rainer Z <rai42>
Submitted:  Tue 12 Dec 2017 11:57:30 PM UTC
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Originator Name:  * rai42
Open/Closed:  Open Release:  * 6.2
Programmer hardware:  FTDI FT232RL Device type:  ATmega8
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

Tue 12 Dec 2017 11:57:30 PM UTC, original submission:  

SETUP:

Using a custom board with ATmega8 and FT232RL and the following config/connections:

programmer
  id    = "ftdi_uni_uC";
  desc  = "FT232R Synchronous BitBang";
  type  = "ftdi_syncbb";
  connection_type = usb;
  baudrate = 38400;
  reset = 7; #RI
  sck   = 3; #CTS
  mosi  = 6; #DCD
  miso  = 5; #DSR
;

I used avrdude 6.2 (but the relevant file ft245r.c is identical with 6.3).


THE PROBLEM: I find that device initialization often (about 50% of tries) fails as follows:

$ sudo ./avrdude -p m8 -c ftdi_uni_uC -P ft0

avrdude: Device is not responding to program enable. Check connection.
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

---
Investigating with an oscilloscope, I found that during ft245r_open() the signals behave as follows:

1) start with RESET=1, SCK=0
2) calling ftdi_set_bitmode (line 614) => sets RESET=0
3) calling ft245r_drain (line 638) =>
  shortly pulses RESET=1 and SCK=1 simultaneously, then back to 0
  This seems to happen due to the switching of bitmodes back&forth in ft245r_drain().
4) calling ft245r_send (line 640) - set output to ft245r_out => sets RESET=1

This is followed by the actual init sequence in ft245r_initialize().

It appears that the simultaneous pulsing of RESET and SCK (step 3 above) puts the ATmega (already powered up since VCC is not controlled) in an undefined state. This is not (always) fixed by the folloiwing init sequence, despite pulsing RESET high in accorance with the datasheet.

I assume that programmers that control VCC will not be affected by this problem, since the AVR is not powered up before ft245r_initialize() runs.


PROPOSED PATCH (see attached ft245r.patch):

  • change ft245r_drain() to use ftdi_read_data until buffer is empty, instead of bitmode switching
  • call ft245r_drain() before setting up the reader thread, rather than after (make sure reader thread starts with empty buffer).

This fixed the issue for me (i.e. initialization and further operations now work reliably).

Rainer Z <rai42>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #42625:  ft245r.patch added by rai42 (1KiB - text/x-patch - Patch to ft245r.c)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rai42 (Submitted the item)
  • -email is unavailable- added by rai42 (avrdude FT232 syncbb init)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-12-12 rai42 Attached File- Added ft245r.patch, #42625
        Carbon-Copy- Added rai42

    Back to the top


    Powered by Savane 3.9