The utility was written in Visual C#. I hope somebody familiar with C# is able to test the code in his failing setup and figure out the problem, nothing else, please don't ask me about of how integrate this code to another project because certainly I'm not an expert in C#. This code is intended for dudes that really have a basic knowledge in programming and believe can help. Just remember this code works perfectly in my PC, running Vista and using the Official FTDI cable.ArdupilotConfigTool.zip
David,
I believe that there is a separate problem with the EM406 GPS. I'm afraid my software fix will not fix that problem. For now, it seems that the accepted fix is to disconnect the GPS during uploading.
I am using the u-blox GPS, not the EM406, so I don't have first hand experience with the GPS issue. I read in another thread that someone thought that pin 6 of the GPS connector was grounded, when it should not have been connected. Since pin 6 is a signal that is not needed by the AP, you could snip that wire on the cable from the GPS to the AP, and see if that fixes the problem.
Damon
Reto, The official FTDI cable is very strong. Is well protected and can be used in the grass, sand, whatever and it will survive (you can even walk over it, that is normally specially when you are busy in the field)... The Sparkfun module is fine, but i suggest not to expose it to much to the dirt, you can use shrink tube, but the dust can still go in and don't try to walk over it!
As already mentioned, i can't test it because i don't have a failing hardware.... What Damon did was exactly what i wanted to try out. But i was unable to get a "failing" SF module. But actually this idea came to my mind after Damon noted that the pins in the SF module and the FTDI cable were different. So all the good points are for Damon!
I have just tested the fix and I can conform it works! (I am using a laptop running Windows7 and the Sparkfuun 3.3v FTDI board)
Thanks very much Damon, this is what open source is all about!
Jordi - not a problem, glad to help. I'm still confused about one thing - what pin does the official DIY drones cable bring out, DTR or RTS? From the schematic on FTDI's site, I thought that it was RTS, in which case the Sparkfun board should work, and the official cable should not.
Either way, I'm hoping that pulling both low and adding the delay should solve everyone's problems.
I should explain a bit about what I've done here. I determined that my problems with uploading were due to the cable not resetting the ArduPilot. You should note that not all problems with uploading are due to this - as Chris mentioned above, you must also be sure that you have good electrical connections and the FTDI drivers are up to date.
I have two FTDI cables, the 5V breakout from Sparkfun and a TTL-232R-3V3. I think the latter came directly from FTDI, but I'm not positive. It has the same part number as the one from Adafruit and DIY Drones, but I am not certain it has the same functionality.
Anyways, the ArduPilot is designed to reset when pin 6 of the FTDI connector is driven low by the FTDI interface. On my sparkfun cable, pin 6 is wired to DTR on the FTDI chip, but on the other cable it is wired to RTS. The original config tool code enabled DTR to reset the AP, but did not do the same for RTS, so only the Sparkfun cable worked for me.
are what pull the DTR and RTS pins low (they are active low).
Furthermore, I was getting some errors when I uploaded to the AP with the shield connected. I have very limited test equipment available (a multimeter!), but I guessed that possibly the reset was not being pulled low enough for a long enough time to actually reset the board. So, I added in a delay with Thread.Sleep. As I noted before, this delay could probably be shorter, but I don't think it really hurts to be a bit extra long.
The lines:
serialPort1.DtrEnable = false;
serialPort1.RtsEnable = false;
return the reset pin to the hi state, so that the CPU can run and the upload can commence. I'm not certain these are needed, I'm still thinking about this...
Comments
I believe that there is a separate problem with the EM406 GPS. I'm afraid my software fix will not fix that problem. For now, it seems that the accepted fix is to disconnect the GPS during uploading.
I am using the u-blox GPS, not the EM406, so I don't have first hand experience with the GPS issue. I read in another thread that someone thought that pin 6 of the GPS connector was grounded, when it should not have been connected. Since pin 6 is a signal that is not needed by the AP, you could snip that wire on the cable from the GPS to the AP, and see if that fixes the problem.
Damon
Have you tried uploading with the GPS disconnected? Please try that and report back with your results.
If that fails, try disconnecting the shield and connecting the FTDI directly to the AP.
Damon
If you want to split hairs, look here.
As already mentioned, i can't test it because i don't have a failing hardware.... What Damon did was exactly what i wanted to try out. But i was unable to get a "failing" SF module. But actually this idea came to my mind after Damon noted that the pins in the SF module and the FTDI cable were different. So all the good points are for Damon!
Thanks very much Damon, this is what open source is all about!
Either way, I'm hoping that pulling both low and adding the delay should solve everyone's problems.
I have two FTDI cables, the 5V breakout from Sparkfun and a TTL-232R-3V3. I think the latter came directly from FTDI, but I'm not positive. It has the same part number as the one from Adafruit and DIY Drones, but I am not certain it has the same functionality.
Anyways, the ArduPilot is designed to reset when pin 6 of the FTDI connector is driven low by the FTDI interface. On my sparkfun cable, pin 6 is wired to DTR on the FTDI chip, but on the other cable it is wired to RTS. The original config tool code enabled DTR to reset the AP, but did not do the same for RTS, so only the Sparkfun cable worked for me.
The lines:
serialPort1.DtrEnable = true; //Restarts ardupilot
serialPort1.RtsEnable = true;
are what pull the DTR and RTS pins low (they are active low).
Furthermore, I was getting some errors when I uploaded to the AP with the shield connected. I have very limited test equipment available (a multimeter!), but I guessed that possibly the reset was not being pulled low enough for a long enough time to actually reset the board. So, I added in a delay with Thread.Sleep. As I noted before, this delay could probably be shorter, but I don't think it really hurts to be a bit extra long.
The lines:
serialPort1.DtrEnable = false;
serialPort1.RtsEnable = false;
return the reset pin to the hi state, so that the CPU can run and the upload can commence. I'm not certain these are needed, I'm still thinking about this...
-
1
-
2
-
3
of 3 Next