 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : simplest 32MX150 ICSP
  Page 13 of 28   |
|||||
| Author | Message | ||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Update: have erased and reflashed my first PIC32. It is crazy, but a cheap FT232 really is enough. Much code cleanup needed, and I want a short copyright/licence that names me as author but otherwise allows use of the code for free - any suggestions? (GPL is rather painful & long.) John |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
Excellent result. Congratulations, I am looking forward to trying it out. This is what I used for projects such as the ASCII Video Terminal Copyright (C) 2014 Geoff Graham (projects@geoffg.net)
All rights reserved. This file and the program created from it are FREE FOR COMMERCIAL AND NON-COMMERCIAL USE as long as the following conditions are aheared to. Copyright remains Geoff Graham's, and as such any Copyright notices in the code are not to be removed. If this code is used in a product, Geoff Graham should be given attribution as the author of the parts used. This can be in the form of a textual message at program startup or in documentation (online or textual) provided with the program or product. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by Geoff Graham (projects@geoffg.net) THIS SOFTWARE IS PROVIDED BY GEOFF GRAHAM ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The licence and distribution terms for any publicly available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution licence (including the GNU Public Licence). Geoff Graham - http://geoffg.net |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Well done JohnS. I am still in the Netherlands (Scheveningen - The Hague) and won't be home until September some time so no developments from this end for a while. Heading off to Manchester UK in a few days. Not looking forward to the winter on return home. The days and evenings are glorious here. David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Thanks, Geoff & David. So long as I can tweak the name & maybe body a little then that looks OK. One thing I have to figure is a convenient (for me) way to make an EXE as I don't usually run Windows. I went for libusb which exists for Windows so that part should be doable. (I want to release the source of course but an EXE seems more convenient for people.) John |
||||
| Keith W. Senior Member  Joined: 09/10/2011 Location: AustraliaPosts: 118 |
WOW! Congratulations John. I am looking forward to your story of the steps taken. Are you managing with ICSP communication for the full programming task? An .EXE will be convenient for all, but the source will also be interesting. Keith W. |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
Fantastic, Great work John, How is the hardware connected? Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
donmck Guru Joined: 09/06/2011 Location: AustraliaPosts: 1314 |
Fabulous work John. I believe that will really make a difference to the growth of MM and variants. Let the clones begin. 
Cheers Don... https://www.dontronics.com |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Correction: I'm using libusb but doing it through libftdi. The code is parameterised such that mostly it doesn't care what the hardware is that it runs on (see below). It doesn't really depend on FTDI (or libusb/libftdi), just can use that. I do things like detecting the chip's DEVID and erase directly but then I load the Microchip PE and use it. Using the PE is "faster" - that is it is the fewest number of bytes sent and doing all this over 2-wire ICSP via a PC and a USB board is horribly slow per byte. I power the target separately, then have 4 wires from the FT232 board, for: MCLR, PGC, PGD & GND (that's power and 4 for Microchip's "2 wire" ICSP). Any FTDI chip with their GPIO API should work but the point was to use a cheap one such as FT232 I had to fit a few pins to the FT232 board. The code has #defines for the pins so you can use any that work as GPIO. You need 3 for: MCLR, PGC & PGD. (And GND.) It's so slow that ideally you'd burn a bootloader of some type then move to using it, but you don't have to. I've successfully erased an Olimex Pinguino MX220 board & reflashed it with its HID bootloader. I plan to tweak my code and download it to that board, which should then be a fast version of what I now have (with the MX220 taking the place of my PC & FT232 board, able to program other PIC32 boards). I mentioned above that the code is parameterised so this is the easy part. There are just a few very short helper routines to do. Because it doesn't need FTDI it could be put into a umite (or maximite) if there's room and should run quickly then. That way any 'mite can program any PIC32, although I think a version in MMBasic as MOBI is doing is a better idea in terms of coolness (plus anyone wanting to read it won't necessarily already know C). There are also cheap PL2303 & CP2104 boards with some GPIOs so the code should port to those as well but I may get bored!! Those boards are cheaper than the FT232 ones. I think it could be quite a bit faster if a "cheat" circuit is used where PGD is not treated as bidirectional. Instead, 2 wires are used for PGD, one to O/P PGD and one to I/P it. I didn't like the look of the circuit (it has a resistor to limit what happens when both the O/P and the target are driving PGD) so haven't tried it (yet). Another way to speed it up (when using a PC & USB FTDI board) would be to send a custom PE down to the target's RAM and then use more GPIOs. In essence, to get away from 2-wire ICSP. The 2-wire is slow because of having to turn PGD round on every few clocks and each clock is in effect a USB transfer taking some ms (whereas a uC would take us, so it's 1000 times slower from the PC doing it this crazy way) John |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
John, How long does it take to program a uMite using this method? Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
I just tried it. It's about 55 minutes (for the roughly 110K). But when I powered up the board to see if it worked it is odd and upon reading its contents nearly all is erased. Is that Geoff's umite code thinking an erase/update was wanted? How do I tell? How do I stop it? John |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
The reset code looks for a short on the console Tx and Rx lines then erases and BASIC program. It does not erase MMBasic itself so I doubt that that could be the issue. The uMite firmware is also partially stored in the bootload area of the flash. Are you programming both the bootload and main flash areas? Tweak away. The copyright notice is not copyrighted!! Geoff Geoff Graham - http://geoffg.net |
||||
vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
I'm glad you are facing (congratulation for your success with FTDI) this. Because the personal experience is the most important. The culprit is the toolchain used by Geoff. Only Pickit3 knows how to handle it. Is a limitation impossible to overcome, unless Geoff migrate the project to xc32 (one of the versions proved to work with Pickit2 or any other solution) Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Geoff, thanks. I'm programming boot & main flash areas (that's why it takes forever). I don't think it's any toolkit, chances are it's something I've got wrong or misunderstood in Mchp doc. (Not heard back from them about the bugs and shortcomings I reported.) Back to the usual hair-tearing-out. John |
||||
| vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
But you must be sure. I'm pretty sure that you will be able to burn a sample compiled with mikroC PRO for PIC32 using your programmer and your procedure. And you won't do the same with an identical (at C source level) sample compiled on Geoff's toolchain. You should do these kind of tests before pulling out any more hair. Geoff, can you propose a source sample (blink two LEDs, the ones on Pinguino32 MX220 - John can give you the details or the schematic) and provide a compiled .hex file for tests? Something which can be then compiled on mikroC and XC32 toolchains. I really think that you guys can't go further without this test. Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
What??? That's a ridiculous post. There's no way the chip knows what toolkit made the hex that I then download as bits. All the PIC32 sees is pulses on PGC, PGD etc and sends back pulses when asked. It's got no way to know what toolkit was involved at any point in those pulses. John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Update: I've now discovered that the PE's ROW_PROGRAM can apparently report success despite not having done any programming. I don't understand what's going on but am trying to work around it. John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Got it to program a umite :) It's prone to fail part way through for no reason I understand, maybe I have dubious hardware or my code has some timing thing I've not spotted. When it fails I restart with a Resume flag and it continues and gets there eventually. I added a Verify option to make sure it's worked. About an hour for 100KB+ whether umite's hex or ByPic Basic - I've tried both and they both work. Needs more work, the error recovery (the user) is rubbish! John |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2948 |
Sounds like good progress you're making there. 
Keep going with those 'bits' as it sounds like you are very close to something very useful. WW |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
I'd just get a PICkit3. Oh, I already did ages ago! I suppose a very cheap, crude alternative is some use & the code can get shoved various places, hopefully. John |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
My thoughts on the next steps. John’s recent success and suggestion regarding use of (I think) a Pinguino-MX220 board have prompted me to consider some options. The drawback to using bit banging with the FTDI USB chip is that it has proved to be slow, but if just the cumbersome ICSP 4 sequence clock process could be drastically speeded the total time may be acceptable. Therefore I propose that perhaps just this “clock” routine be performed by a second processor with the balance of the task still performed by the PC. A single byte via USB from the PC could trigger a “clock” sequence process upon ICSP output pins and return any data to the P.C. This crude method could be expanded to encompass 32 bit transfers by perhaps transferring 5 bytes to or from the PC where the first byte can indicate the ICSP communication type required. Most communications require 32 data bits when programming and this method will speed the process. By using something like the MX220 board the FTDI USB interface chip is replaced with a USB capable PIC32MX. Geoff’s ASCII Terminal board contains a similar chip. It would be possible to use the Terminal board as the ICCSP programmer. It contains (once programmed first time) a boot loader that would enable a program to be loaded to become a “smart clocking” USB to ICSP interface. The existing ICSP connector would require a mod to enable MCLR to be controlled for the subject chip to be placed into ICSP mode; alternatively as the Terminal processor is a DIP chip some wires could be soldered from CPU pins for a separate connector, already many are brought to board pins. Possibly there is some space still within the Terminal CPU flash for a small alternate program that could be jumped to by changing an input pin voltage? My hope here is to defray the cost of the programmer by causing the ASCII Terminal board to do a second task. Any comments? Keith W. |
||||
| Page 13 of 28 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
