Created Tue, 17 May 2016 01:19:51 +0000 by andcvi
Tue, 17 May 2016 01:19:51 +0000
Correct me if I am wrong but as I understand the MPIDE IDE is no longer being supported, so will eventually have to use the Arduino IDE.
I have setup Arduino IDE 1.6.7 with release version chipkit-core-windows-16778039.master.v1.1.0-18-gcd8bbd3.zip
It compiles my programs without problems, but uploads via the the CMOD board serial port bootloader fails, all I get is pic32prog version 2.0.186 no target found, I have no problems uploading when using the MPIDE IDE.
Does pic32prog have to use the pickit3 rather than serial port upload, if that is the case how do I use the serial port bootloader in the Arduino IDE.
Tue, 17 May 2016 09:06:30 +0000
pic32prog is the program that is used in MPIDE for programming the chipKIT boards - unless you have a very old version of MPIDE that still uses avrdude. It talks STK500 the same as avrdude through the UART port.
If it's not detecting the board then it may be that it's not resetting the board properly. Check that it does actually reset when you tell it to program (LED flashes). There have been a lot of issues with the FTDI drivers of late.
Personally I would recommend switching to UECIDE rather than the Arduino IDE - simply because it is about 1000x better, and I wrote it :) Support for the chipKIT boards is considerably better than in the Arduino IDE.
Thu, 19 May 2016 02:16:30 +0000
Thanks for the reply, the mpide IDE I use is mpide-0150-windows-20150820.
I downloaded your UECIDE.0.8.8.alpha22 and it has the same problem as Arduino.1.6.7 IDE using pic32prog, if I use avrdude option then it uploads the code without problems.
The FTDI drivers I had loaded were version 188.8.131.52 so updated to the latest version 184.108.40.206, again same problem, this is with Windows XP SP3, so installed UECIDE on Windows 7 SP1 with latest FTDI driver same problem.
The Cmod appears to be reset using pic32prog because the bootload led goes out, but does not flash.
avrdude works ok so it must be a problem with pic32prog.
Thu, 19 May 2016 09:57:13 +0000
There is a known issue with pic32prog in windows using some of the factory shipped bootloaders from Digilent. If you have a hardware programmer you could try updating the bootloader to the current open-source version which you can get here: https://github.com/majenkotech/PIC32-avrdude-bootloader/tree/digilent/BootloadersCurrent-hex
Thu, 19 May 2016 10:28:44 +0000
Virtual XP machine, UECIDE 'alpha22, cmod with freshly installed "stock" bootloader (downloaded from digilent's site) and it programmed straight away.
The FTDI drivers I am using are the last "zip" XP version: http://www.ftdichip.com/Drivers/CDM/CDM%202.08.24%20WHQL%20Certified.zip
Sun, 22 May 2016 03:04:43 +0000
Thanks for your help.
I tried the 2.8.24 FTDI drivers, still no go, also tried the original Cmod bootloader and the one from your pic32-avrdude-bootloader and I tried the FTDI drivers on another windows xp pc same result.
I also used MPLABX and your pic32-avrdude-bootloader code to compile the Cmod bootloader, I use the chipkit xc32 compiler and it compiles without any problems, again same result.
I should have stated that I have made a Cmod compatible board using the Cmod bootloader without external crystal osc, I use the internal osc, since I had no problems with mpide and avrdude. I used a serial port monitor to log data between my Cmod board and pic32prog, don't know if this will help.
I was thinking that using the internal osc maybe causing the 115200 baud rate to be slightly off, but if avrdude has no problems then pic32prog should work also.
If you plan to keep the avrdude option in your UECIDE then I will continue using the avrdude option.
[attachment=0]pic32prog serial monior.zip[/attachment]
Sun, 22 May 2016 10:12:37 +0000
I wasn't planning on keeping avrdude in UECIDE for the PIC32 but I certainly can do - I'll build a programmer plugin for the preview version of UECIDE so it stays available.
That trace is hard to understand what is going on. Better would be to manually run pic32prog in debugging mode and capture the output. I'm not entirely sure how you'd do that in Windows, but in Linux I run:
$ ~/.uecide/cores/chipkit/tools/linux64/pic32prog -d /dev/ttyUSB0 -DD
That will spew out everything that is sent and received along with lots of extra debugging information about what it is doing when. Of course, you'd need to find that pic32prog executable (in /Users/<you>/AppData/Local/uecide/cores/chipkit/tools/windows I think) and change /dev/ttyUSB0 to the COM port you are using. You can turn on verbose command execution in UECIDE to see the full command that is being run and copy and paste that into a command prompt and add -DD to turn on debugging.
Mon, 23 May 2016 04:13:42 +0000
I used the original Cmod bootloader and used an 8mhz resonator across the osc pins and it made no difference with pic32prog.
I did as you suggested and ran pic32prog in debug mode from a terminal and the results are in the text file. Hope this helps in finding out why it doesn't work with my setup.
have included the original Cmod bootloader from Digilent and my recompiled Cmod bootloader using intosc and pin 33 & 34 for bootload serial port
[attachment=0]pic32prog debug output.zip[/attachment]
Wed, 25 May 2016 03:04:51 +0000
I managed to get pic32prog to upload.
My FTDI USB serial cable has only RTS and CTS lines and have been using the RTS line to reset the board, tried CTS but did not reset the board, I then tried another USB serial cable which had the DTR line but this did not reset the board.
So the next thing I tried was to just have GND, TX, RX connected and manually kept the board in reset until I pressed the compile and upload button and then it worked, obviously it has to do with timing when using the RTS line which in my setup does reset the board.
Another thing on my board I have the the MCLR pin connected to a 10k resistor and a 0.1uf capacitor, do you think the capacitor in the reset circuit maybe the problem. I haven't tried yet as I have a broken hand so am one handed for the next couple of weeks.
[attachment=0]uecide manual reset.jpg[/attachment]
Wed, 25 May 2016 08:21:30 +0000
Ah, it's starting to all become clear now.
CTS can never work - it's an input TO the chip that would connect to RTS on a remote device - to look to see if it's clear to send (the other end is signalling it's ready to send).
So RTS is all you have. I thought RTS should work fine in UECIDE - as long as the board is configured to use it. It's related to this post: http://uecide.org/forum/viewtopic.php?f=14&t=419&start=30
RTS will struggle in other IDEs that don't know about it.
Can you upload the schematic of your reset circuit, including the RTS (or DTR) connection?
Thu, 26 May 2016 03:35:39 +0000
I connected my saleae logic analyzer to the TX RX and RTS lines to my pic32 Cmod clone board and logged the data for manual and RTS reset using pic32prog and also avrdude RTS reset, if you can download saleae logic analyser software then you can view the data logs in more detail. my saleae version software is 1.1.15.
[attachment=1]saleae logic uecide files.zip[/attachment]
If you look at the image files you can see that with avrdude it sets the RTS line low for about 214ms then high for about 293ms the low again for 4ms then high again, with pic32prog it goes low for 216ms then high for 295ms then stays low for about 3.2 secs thus keeping the PIC32 in reset.
my reset circuit is just a resister and capacitor of 10k to +5v and 0.1uf to ground and the USB FTDI TTL cable RTS line is just connected to the MCLR. I also removed the 0.1uf capacitor and it made no difference.
hope this helps.
[attachment=0]pic32 reset circuit.zip[/attachment]
Thu, 26 May 2016 13:16:47 +0000
Ah. You need a 100nF inline in your RTS signal to convert the signal into a pulse. Check the schematics of the CMOD and other chipKIT boards to see what I mean.
Sent from my SM-T555 using Tapatalk
Sat, 28 May 2016 00:47:52 +0000
Inserting a 0.1uf capacitor in line after RTS fixed the problem. pic32prog now works in UECIDE.
I also tried Arduino IDE 1.6.7 and it works as well with pic32prog, I also noticed that in the Arduino IDE pic32prog also verified the upload, but UECIDE did not, is it possible to have a verify check box in preferences to verify the upload, or it is verifying not necessary.
Also thanks for your help with this problem
Sat, 28 May 2016 09:51:47 +0000
I have found that verifying is never really necessary - and when you're uploading a 2MB sketch to a Wi-Fire board it makes a very long process insanely long.
Yes, an option in preferences can be added, and I will look into it.