How does mpide automatically reset the target device?

Created Sat, 28 Jun 2014 04:10:23 +0000 by woodjmichael

woodjmichael

Sat, 28 Jun 2014 04:10:23 +0000

Title says it all. I'd like to know whats going on here. I'm Running MPIDE with my chipKIT Max32 board.

Hardwareically speaking, the Max32's FT232 USB-TTL converter does the reset, probably with the RTS# output (though DTR# is capacitively coupled as well) pulling MCLR low. Thus I would expect any incoming transmission to trigger this, but clearly thats not the case.

I'm trying to replicate mpide's great feature of automatically resetting my Max32 target device with the avrdude bootloader, if you're wondering what the goal is here. I'm actually using the MPLAB X editor (more features, debugging, I dont seem to have the problems that a lot of people complain about) and would love to be able to spit out a .hex file and use avrdude to quickly write to boards without a PICkit.

Thanks! Mike

EmbeddedMan

Sat, 28 Jun 2014 07:32:40 +0000

Mike,

Every time the serial port is opened, the FTDI chip resets the chipKIT MAX32/UNO32/uC32, etc. Notice in the schematic that the #DTR line from the FTDI chip is tied to the PIC32's RESET line via a .1uF cap. So every time there's a falling edge on DTR (which is normally 'high', and becomes 'asserted' low every time the serial port is opened) causes a reset of the PIC32, which then runs the bootloader for at least 2 seconds.

Note also that some versions of the FTDI driver (I believe the latest version for Mac OS) do not automatically assert DTR anymore - Keith at Digilent is having some trouble with this, and can correct me if I've gotten any of this wrong.

*Brian

woodjmichael

Sat, 28 Jun 2014 17:45:48 +0000

That sounds plausible enough (I was wondering about that DTR#..) but when I run avrdude the following happens:

1. I tell avrdude what COM etc.. everything looks great.

2. avrdude starts up and presumably opens the COM port (since it wasn't open to start and it must be open to send commands to the bootloader).

3a. If the bootloader is the only app on my Max32, the avrdude sees the boatloader and starts to program immediately.

3b. Else if I have an app (say, blink.hex) programmed in addition to the bootloader I have to reset the target before avrdude will see the bootloader.

I dont see how avrdude could be getting to the point of looking for the bootloader without having opened the COM port (which should have reset the Max32 you say). So I'm wondering if there isn't something else going on.

MPIDE resets the Max32 easy enough, so I think my driver (and the configuration of the FT232) is fine.

Thanks for the prompt reply!

Mike

majenko

Sat, 28 Jun 2014 19:20:55 +0000

MPIDE does (or should do) a manual toggle of the DTR# line to force a microcontroller reset. This gets (or would get) around the FTDI driver problem.

Certainly UECIDE does a manual toggle to force a reset. It also does one after the upload is complete to force another reset.

woodjmichael

Sun, 29 Jun 2014 02:09:19 +0000

By 'toggle' you just mean it opens the COM port? I can manually throw the DTR# pin by opening the COM port using a putty-like client.

Again, avrdude seems to get around this somehow. Strange. Also the author here admits that sometimes avrdude is able to toggle the DTR# pin and other times not. This is consistent with my own experience.

woodjmichael

Sun, 29 Jun 2014 02:49:33 +0000

I think I'm set now. Just some peculiarities of stk500v2.

https://code.google.com/p/arduino/issues/detail?id=806

bperrybap

Mon, 27 Oct 2014 01:29:42 +0000

MPIDE does (or should do) a manual toggle of the DTR# line to force a microcontroller reset. This gets (or would get) around the FTDI driver problem. Certainly UECIDE does a manual toggle to force a reset. It also does one after the upload is complete to force another reset.

That is a risky thing to use or depend on. DTR is normally controlled by the OS and is dropped low when the device is opened before the open() call returns so the application is often limited in its use. In some situations/operating systems applications are not allowed to mess with DTR.

A much better solution is to use RTS instead of DTR. RTS can be controlled in s/w by the application and is normally not monkeyed with by the OS prior to the application getting control of the serial port device.

It was sad that the Arduino folks picked DTR for autoreset as it is a h/w solution to a s/w problem. The cap was needed to turn the DTR level signal into a pulse.

When using RTS, there is no need for this translation as the s/w has full control over the output state of the pin.

The reason the Arduino folks originally went with DTR over RTS is that it could be used with the existing avrdude.

Now that avardude has been updated with the "Arduino" protocol which toggles RTS, there is no reason to continue using DTR.

When using RTS instead, you can get the best of both worlds. You can open the port with something like a serial monitor and not reset the device but then have tools like avrdude reset the device to force the device back to the bootloader.

I use RTS instead of DTR on all my AVR based devices. This allows me to connect to the AVR board using a serial monitor program without resetting it but still allows autoreset for uploading using the IDE or avrdude.

--- bill

majenko

Tue, 28 Oct 2014 16:03:17 +0000

I completely agree with you, but alas we are stuck with what we have, which is based on Arduino, which itself is based on the principle of "It works well enough for our needs".

UECIDE, by the way, has individual configuration settings for RTS and DTR, so it can just toggle RTS if you want, or just DTR, or (the default) toggle both.