mcuee
commented
2 years ago The code has changed quite a bit, I am not so sure wether this patch is still valid or not.
The patch is probably against this older version. https://github.com/avrdudes/avrdude/blob/17bb2a10cd6776dfd2b735a83e45b1c605c06622/ft245r.c
There are two changes in the patch. 1) change ft245r_drain() to use ftdi_read_data until buffer is empty, instead of bitmode switching
--- ft245r.orig.c 2017-12-07 23:37:36.586002368 +0100
+++ ft245r.c 2017-12-13 00:33:48.268135055 +0100
@@ -214,6 +214,7 @@
static int ft245r_drain(PROGRAMMER * pgm, int display) {
+#if 0
int r;
unsigned char t;
@@ -227,6 +228,17 @@
while (head != tail) {
ft245r_recv (pgm, &t, 1);
}
+#else
+ int r;
+ unsigned char buf[0x1000];
+
+ do {
+ r = ftdi_read_data (handle, buf, sizeof(buf));
+#if FT245R_DEBUG
+ fprintf(stderr,"drain: %d\n",r);
+#endif
+ } while (r==sizeof(buf));
+#endif
return 0;
}The current code is still using bitmode switching. https://github.com/avrdudes/avrdude/blob/main/src/ft245r.c#L321
2) 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).
@@ -623,6 +639,11 @@
goto cleanup;
}
+ /*
+ * drain any extraneous input
+ */
+ ft245r_drain (pgm, 0);
+
/* We start a new thread to read the output from the FTDI. This is
* necessary because otherwise we'll deadlock. We cannot finish
* writing because the ftdi cannot send the results because we
@@ -632,11 +653,6 @@
sem_init (&buf_space, 0, BUFSIZE);
pthread_create (&readerthread, NULL, reader, handle);
- /*
- * drain any extraneous input
- */
- ft245r_drain (pgm, 0);
-
ft245r_send (pgm, &ft245r_out, 1);
ft245r_recv (pgm, &ft245r_in, 1);
This is probably not relevant any more as the current code has changed and indeed call call ft245r_drain() before read. https://github.com/avrdudes/avrdude/blob/main/src/ft245r.c#L959
/*
* drain any extraneous input
*/
ft245r_drain (pgm, 0);
ft245r_send_and_discard(pgm, &ft245r_out, 1);
return 0;
rai42
Tue 12 Dec 2017 11:57:30 PM UTC
Programmer hardware: FTDI FT232RL
Device type: ATmega8
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):
file #42625: ft245r.patch
This issue was migrated from https://savannah.nongnu.org/bugs/?52653