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.

[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."

[Chris21]

Perhaps disconnect DTR to Reset, set boot pins and power cycle board, then program.

[Andrew C]

That worked once I set the serial parity to even. Still doesn't work with the USB to serial chip controlling the boot and reset pins.

having the same problem

[Andrew C]

Just and update....I did as Chris mentioned, I just forced each boot pin to the bootloader state. it didn't work until I put the serial parity to even. Then it connected and read fine. I tried this with the boot0 pin connected to RTS, and the results are still as i described earlier. I guess that means it is something in the FT232R chip.

[Andrew C]

I believe I found the issue. The STCubeProgrammer software makes a new connection every single time you want to read/program. The issue is that it triggers the port to reset, which leads to rts and dtr being pulled low for a moment. You can't fix this with with inverting the rts and/or dtr because it will just pull it to the opposite direction for a moment. So, the issue is that during the connecting phase, it will always pull the chip out of boot mode when used in conjunction with the STCubeProgrammer due to the momentary port reset that happens. 

So, to get this to work, i would need to do the following...

Make sure the boot pins are in the right states (boot0 high, boot1 low for this chip), then trigger a low pulse to put the chip in reset, then once the pulse goes back high, it will enter boot mode. Once I finish uploading the code, i need to reset the chip once more, but take the boot pins out of the programming before doing so. But this needs to happen AFTER I make a connection. Does that sounds right?

So basically, TLDR, I can't use the STCubeProgrammer because I can't control the initial sequence of events.

 

[Andrew C]

Final Reply....

Yes, this was due to the FT232 reasserting pins after a connection. I tried this on a CP2102N (after the grueling IDE download), and it worked once I preprogrammed the dtr and rts to the correct initial state.