Fixed DTR/RTS bootloader

[davidrojas]

It was firing twice, when connecting and reconnecting after clock switching, resetting again the device.With this fix it works fine in mac, but in Linux apparently there is a bug in the drivers for the usb-to-serial chip that we use (CP2104), causing a reset on the RST line whenever a serial connection is opened.

[JelmerT]

Sorry for the late reply!

This is a good catch! I don't have any hardware that supports the DTR/RTS pin toggle to invoke the bootloader, so I never noticed the clock switching wasn't working properly.
If I understand correctly, after doing the clock switch, the chip was reset again, which switched it back to the internal (slower) clock?

Did you ever notice problems with this @bradjc ? (He implemented the feature originally).

Code looks good to me 👍

[JelmerT]

Concerning the bug in the CP2104: did you find away around this? And do you know if the CP2102 has the same problem?
This would mean that you can never get the chip to use the external clock source on Linux (when using a platform with the auto reset feature and that serial driver / chip).

[davidrojas]

I have been looking into that and the last spec of the RS232 standard apparently says that when opening a connection, RTS and DTR should be kept low (if not using hardware flow control). So it is not a bug on linux/windows, it is actually a non-updated driver what makes it work in mac. I tried making another custom board with the FT232RQ (it is a fairly new FTDI, smaller that the older ones that everyone used to use), and it is acting the same. Whenever a serial connection is opened, RTS and DTR is pulled low by the FTDI/CP2104, and is kept that way unless pulled up again with the setDTR/setRTS. Using a custom python script I can communicate no problem, I just call setDTR/setRTS on connect, but with putty or any other serial console it doesn't work.
I'm very surprised nobody has commented on this issue. It is possible that with older FTDI chips (that use a different driver) it behaves differently.

[JelmerT]

I'm not sure how many people are actually using this feature, and if they do, maybe they don't know that uploading should go a lot faster.

When you say 'I can communicate no problem', you're talking about debug over serial coming from the chip. Not uploading with the bootloader, right?

Because if the specs say RTS and DTR need to be low when opening the port (and we can't change the speed on the driver/pc side without closing and opening), that would mean we can never do the clock switching properly. The chip would get reset every time the driver on the pc side opens the port.
Do you have a reference for the RS232 specs?

[davidrojas]

I cannot find the RS232 reference, but there are many people with the same problem in other devices, look at this thread for example: http://ubuntuforums.org/showthread.php?t=1436247
It says there that "the 'new' (1990-ish) RS-232 specification calls for RTS to always be asserted for full-duplex devices. "
When I say I can communicate I mean debugging over serial, just connect and it will reset the board but then set the lines and it comes back to life again. For uploading through the bootloader it works because the cc2538-bsl script already sets the lines the correct way to start the bootloader.
If you don't have any hardware with the RTS/DTR wired to the reset/boot, you still can check this behaviour with an oscilloscope, just any eval board that you have with an FTDI or other usb to serial chip. The moment you open the connection you will see the lines go low and stay there.