firmware uploading with FT232RNL IC to F413

[Andrew C]

I am having some issues with getting UART uploading working. I can read the chip and get it's ID, but it keeps saying it cannot get acknowledgments. 

Everything is directly connected. Serial TX/RX to their corresponding pins and RTS to Boot and DTR to Reset.

At first, I thought it was because the FT232RNL chip has flipped polarity, but we can change this through the FTDI programmer. 

After changing it, I am still having the issue above. Looking online, I see some people put a cap in between the DTR and Reset. Is this actually required? I know they did not on Arduino's. but I always though it was because their bootloader required it since there was no boot pin like on the ST's.

I cycled through all the possibilities for the DTR and RTS configuration in the ST Programmer software, but none of them seem to fix the issue.  

Any guidance on this?

[Chris21]

RTS to Boot and DTR to Reset?

Boot0 pin should be pulled high, and Boot1 pin should be pulled low.

[Andrew C]

Oooofff.....totally missed the boot1 pin.....

[Tesla DeLorean]

The Reset is generally needed as the protocol initially is a one-shot. ie it's not in UART mode, but a TIM mode, and measuring the 0x7F pattern. Noise on other pins the system loader is watching can take precedence, ie a GPS/GNSS receiver that squawks at startup.

I'd suppose the other issues might be noise on the comms signals, or some instability in the clock/baud rate generation, especially at higher rates, but async comms should be relatively tolerant into the 3 to 5% ranges.

Would expect most to be quite robust in the 9600 8E1 range, less so pushing 1 mbaud, depending on the chip implementation.

On the F4 side make sure you have the VCAP caps working effectively (total 4u7 and 1.25V) as these sustain the processor and charge pump for the internal FLASH programming voltage generation.

[Andrew C]

Does the boot1 pin automatically go to that function? It does not seem to be an option in MX cube and I soldered a wire to PB2 (pin 48) and it still gives me the same results. 

[Chris21]

RM:

"The values on the BOOT pins are latched on the 4th rising edge of SYSCLK after a reset. It
is up to the user to set the BOOT1 and BOOT0 pins after reset to select the required boot
mode.

BOOT0 is a dedicated pin while BOOT1 is shared with a GPIO pin. Once BOOT1 has been
sampled, the corresponding GPIO pin is free and can be used for other purposes."