 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 26 of 28   |
|||||
| Author | Message | ||||
G8JCF Guru  Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Keith Ah, Windows Classic View, I'd forgotten all about that ! Re the speed of the connection from the PC to the uMite, I didn't find that running at 38400 vs 230400 made much of a difference if at all, and compared to the "faff" of having to use "option baudrate", I saw no gain from requiring high speed. Now of course once the 4 phase clock s/w is converted into a C plugin, the comm time from Windows to uMite would well become a significant delay, but I'll deal with the BPS issues that will throw up when I get there. Thanks for the info Peter The only Konstant is Change |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
i've been having a look at pic32prog recently, a most excellent piece of code released under the GPL licence - meaning that all changes we make must be released back to the public. it for programming pic32 processors, including the 32MX150 and 32MX170, supporting several different programmers, including pickit2, pickit3, and several based FTDI's FT2232 usb to parallel bridge. while several forum members have spent hundreds of hours tackling the complexities of processing a .HEX file down to the necessary manipulations of PGC and PGD, pic32prog accomplishes 99% of this already. as such, with a view to kicking off again the project to produce a non-programmed ICSP interface for programming micromites from scratch, i'm proposing we (as a community) create a new extension for pic32prog to achieve this. pic32prog divides the supported programmers across 5 files: adapter-an1388-uart.c adapter-an1388.c adapter-hidboot.c adapter-mpsse.c adapter-pickit2.c the one that we are interested in is adapter-mpsse.c which contains the bit-banged interface. there are a couple of levels at which we may substtute the interface to an alternative ("simplest") programmer, but for the moment i'm going to concentrate on getting set up with the source to pic32prog and the C compiler. the easiest compiler to use for windows is MinGW (Minimalist GNU for Windows). simply go to this page: http://sourceforge.net/projects/mingw/files/ and click on the link reading "Download mingw-get-setup.exe (86.5 kB)". this tiny setup program is an installer from which you can select the components you want to install, later add other components, or remove them. i just installed "mingw32-base" from 'Basic Setup' - right click and select "Mark for Install", then do Installation -> Apply Changes. the installer will go away for a while downloading some 40mb of files. along the way it asks for one or two confirmations. that is it - you now have a C compiler installed and ready to go. to get the source of pic32prog, the simplest approach is to use a program called DownloadSVN 1.3 which is available from here: http://downloadsvn.codeplex.com/releases/view/54881 download using the link reading "DownloadSVN13.zip", unzip, and click on DownloadSVN.exe to begin. into the SVN Source URL box type: http://pic32prog.googlecode.com/svn/trunk browse to where you'd like the source saved on your hard drive (remembering to create a new folder for it all), leave Type set to SVN, and click "Start". after a minute or two of silence the download of the source code will start. you now have the source code of pic32prog on your PC. the last thing you need to do is tweak the make-mingw file so it will work. you will need to use wordpad (NOT notepad) to change the first 3 lines to look like this: CC = gcc #CC = i586-mingw32msvc-gcc #SVNVERS = $(shell svnversion) that is, remove the # from the start of the first line, and add # to the start of the 2nd and 3rd. # marks a line as a comment. now change the end of the 4th line to be: -DSVNVERSION='"97 test"' wordpad needs to be used because all the files use <linefeed> instead of <cr><lf> to separate lines of text. notepad doesn't recognize <lf> alone and joins all the lines together on screen. you should now be able to click on the 'clean' batch file to delete the old pic32prog.exe file along with any .o files. the old pic32prog.exe isn't much use anyway as it is an earlier version that does not support the 32MX170. now click on 'compile' and once the compiler has finished doing it's thing you will have a brand new pic32prog.exe file that you have just created, and can be used to program micromites using an old pickit2. just drop the .HEX file onto the pic32prog.exe icon and everything will work. pic32prog is even nice enough to turn on the power to the target so no external power supply is required. cheers, rob :-) |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
r97 from Serge fully supports all the PIC32MXx70 series, and if you can't find the .exe for download from Serge's site, then take a look here where you will find a version of pic32prog.exe which supports PIC32MXx70 chips. 73 Peter The only Konstant is Change |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
it is probably more instructive to go the route of downloading MinGW and DownloadSVN so as to build pic32prog oneself. i must admit to being surprised at how straightforward the whole process was. once folks are in a position to build pic32prog themselves, it will be possible for those in the community to get down to the serious task of reworking adapter-mpsse.c so that it can talk to the target through calls to a single function: TDO = ICSPtransaction (TDI, TMS, TDOflag); (where TDI and TMS are passed in, and TDOflag indicates if it is necessary to return the value of TDO) once we figure out how to do this, then a number of different hardware interface models become possible, including John's FT232R, my LM555, and your MMbasic version. i've been studying the layers of adapter-mpsse.c and slowly but surely the mud is starting to become clearer. although, my C training was nearly 30 years ago on mainframes, and the input of others would certainly speed things along. perhaps even Geoff might be able to lend a hand? rob :-) |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Indeed from a point of view of development. But just in case anybody was confused, PIC32Prog can program x70 chips Peter The only Konstant is Change |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
a few weeks back Serge Vakulenko (the author of pic32prog) was kind enough to to create for me a stripped-out template for creating a 'bitbang' unit for pic32prog. this template is available in the svn repository at google code. i've spent a few weeks fleshing out the half dozen marked places in the code to talk to a pic32 down a serial port, and attached is adapter-bitbang.c updated with my efforts. i'm not a C programmer normally, so there are likely a few bugs in there - i've not even tried compiling the code yet. and there is a big hole where the code needs to get the pic32 into ICSP mode. Serge seems to have dropped below the radar again, so some of the other forum members might care to offer suggestions. i've targeted windows, simply because that is what i know. there is no reason the code can not be later be provided with conditional compiles for linux and RPi (using the IO header pins). but for the moment it is probably enough to get it going under windows as a start. it would be good if others could have a look at the attached code, and provide a little feedback on what is there. as always, help from the community in getting pic32prog up and running with these changes would be much appreciated. 2014-09-25_154456_adapter-bitbang.zip rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
attached is an updated adapter-bitbang.c which now at least compiles - i had quite a few tiny syntax errors in there. 2014-09-26_014012_adapter-bitbang.zip rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
attached is some code that may (in theory) work. 2014-09-27_133809_adapter-bitbang.zip this is set up to talk to the JTAG interface of the target pic32, and requires a micromite attached between serial port and target running the following short basic program to decode single-letter instructions from pic32prog, and to respond with the state of TDO where required: SetPin 2, DOUT ' MCLR, connect to pin 1 on target SetPin 3, DOUT ' TDI, connect to pin 16 on target SetPin 4, DOUT ' TMS, connect to pin 14 and 22 on target SetPin 5, DIN ' TDO, connect to pin 18 on target SetPin 6, DOUT ' CLK, connect to pin 17 on target SetPin 7, DOUT ' status LED (via 1k resistor to ground) Pin(2) = 0 Pin(6) = 0 ' the following code needs to be fast start: B = Asc(Inkey$) If (B = 0) GoTo start If (B > &h40) Then Port(3,2) = (B And 3) Pulse 6, 0.010 If (B < &h60) Then Print Chr$(&h30 + Pin(5)); GoTo start EndIf ' the following code can be slow If B=Asc("2") Then Pin(2)=0 ' set MCLR low (target in reset) If B=Asc("3") Then Pin(2)=1 ' set MCLR high If B=Asc("4") Then Pin(7)=0 ' turn off LED If B=Asc("5") Then Pin(7)=1 ' turn on LED GoTo start the reason i've proceeded in this way is simply to get something working - initially i didn't realise that pic32prog didn't talk via a 2-wire PGC/PGD interface. this code here is very much a test to see what happens. it is quite possible that along the way i have got TDO and TMS swapped over, MCLR inverted, or other small errors. but it is a start. once i've got this part working, then the plan is to move back to a 2-wire interface using PDC/PGD and no MicroMite in between. i would much appreciate any feedback. if requested i can post a compiled copy of pic32prog.exe but would much prefer if people could set themselves up to compile it themselves - allowing you to make alterations to the open source code. pic32prog expects a parameter -dCOMn, where n is the number of the comm port. the code will only compile under windows right now. someone needs to suggest a widely used serial port library that allows reading and setting the comm port's status pins that is cross-platform. rob :-) (edited to fix bug in basic code) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
getting very close to being able to program a PIC32, the code now gets this far: C>pic32prog -d com3 Programmer for Microchip PIC32 microcontrollers, Version 1.98 (test) Copyright: (C) 2011-2014 Serge Vakulenko Adapter: com3 Processor: MX150F128B (id 14D06053) Flash memory: 128 kbytes Boot memory: 3 kbytes com3: [BB_4] invalid status = 0089 (no reset) C> the following zip file contains both adpter_bitbang.c as well as the latest micromite basic program for the programming hardware. note that i did have TDI and TMS swapped around, plus was handling TCK incorrectly. seems that in the 4-wire JTAG mode TDO becomes active on the rising edge of TCK, and goes tristate on the falling edge. 2014-09-29_043342_adapter-bitbang.zip the sticking point, where the status error is occurring is in this piece of Serge's code: bitbang_reset (a, 0, 0, 1); mdelay (10); // delay 10mS before sending a command /* Check status. */ bitbang_send (a, 1, 1, 5, TAP_SW_MTAP, 0); /* Send command. */ bitbang_send (a, 1, 1, 5, MTAP_COMMAND, 0); /* Send command. */ bitbang_send (a, 0, 0, 8, MCHP_STATUS, 1); /* Xfer data. */ status = bitbang_recv (a); if (debug_level > 0) fprintf (stderr, "%s: [BB_3] status %04x\n", a->name, status); if (status != (MCHP_STATUS_CPS | MCHP_STATUS_CFGRDY | MCHP_STATUS_FAEN)) { fprintf (stderr, "%s: [BB_4] invalid status = %04x (no reset)\n", a->name, status); exit (-1); } unfortunately i've not been able to get in touch with Serge for his advice. any suggestions from the microchip gurus out there? i feel that either i am not doing the reset part correctly (i've tried inverting MCLR), or that my bitbang_send routine is far too simple and introducing an error - although quite a few commands have been run successfully before this error comes up. help via reply or PM much appreciated. cheers, rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
further progress: the target can be interrogated without error. one of the problems was that MCLR was inverted, along with corrupted TDI data. unfortunately, if given a .HEX file, the result is a bricked pic and the following output. fortunately mplab X can erase and un-brick it. i've added extra output showing TMS, TDI, etc. the format is: nTMS, TMS, header, nTDI, TDI [TMS], footer, read_flag rob :-) C>pic32prog -d COM3 mx150.hex Programmer for Microchip PIC32 microcontrollers, Version 1.98 (test) Copyright: (C) 2011-2014 Serge Vakulenko MCLR = 0 n=6, 111110, 1-0-0, n=32, 00000000000000000000000000000000 [1], 1-0, r=1 TDO = 349200467 (32 bits) MCLR = 1 n=1, 1, 1-0-0, n=5, 00100 [1], 1-0, r=0 n=1, 1, 1-0-0, n=5, 11100 [1], 1-0, r=0 n=0, 1-0-0, n=8, 01111111 [1], 1-0, r=0 n=0, 1-0-0, n=8, 00000000 [1], 1-0, r=1 TDO = 139 (8 bits) Adapter: COM3 n=6, 111110, 1-0-0, n=32, 00000000000000000000000000000000 [1], 1-0, r=1 TDO = 349200467 (32 bits) Processor: MX150F128B Flash memory: 128 kbytes Boot memory: 3 kbytes Data: 134144 bytes Erase: n=1, 1, 1-0-0, n=5, 00100 [1], 1-0, r=0 n=1, 1, 1-0-0, n=5, 11100 [1], 1-0, r=0 n=0, 1-0-0, n=8, 00111111 [1], 1-0, r=0 n=1, 1, 1-0-0, n=5, 10100 [1], 1-0, r=0 done n=1, 1, 1-0-0, n=5, 10100 [1], 1-0, r=0 n=1, 1, 1-0-0, n=5, 00110 [1], 1-0, r=0 n=1, 1, 1-0-0, n=5, 00100 [1], 1-0, r=0 n=1, 1, 1-0-0, n=5, 11100 [1], 1-0, r=0 n=0, 1-0-0, n=8, 00001011 [1], 1-0, r=0 n=0, 1-0-0, n=8, 01111111 [1], 1-0, r=0 n=0, 1-0-0, n=8, 00000000 [1], 1-0, r=1 TDO = 139 (8 bits) MCLR = 0 n=1, 1, 1-0-0, n=5, 00100 [1], 1-0, r=0 n=1, 1, 1-0-0, n=5, 11100 [1], 1-0, r=0 n=0, 1-0-0, n=8, 00000000 [1], 1-0, r=1 TDO = 142 (8 bits) COM3: [BB_4] invalid status = 008e (no reset) n=1, 1, 1-0-0, n=5, 10100 [1], 1-0, r=0 n=6, 111110, n=0, [1], r=0 MCLR = 1 MCLR = 0 now the target is "bricked": C>pic32prog -d COM3 mx150.hex Programmer for Microchip PIC32 microcontrollers, Version 1.98 (test) Copyright: (C) 2011-2014 Serge Vakulenko MCLR = 0 n=6, 111110, 1-0-0, n=32, 00000000000000000000000000000000 [1], 1-0, r=1 TDO = 349200467 (32 bits) MCLR = 1 n=1, 1, 1-0-0, n=5, 00100 [1], 1-0, r=0 n=1, 1, 1-0-0, n=5, 11100 [1], 1-0, r=0 n=0, 1-0-0, n=8, 01111111 [1], 1-0, r=0 n=0, 1-0-0, n=8, 00000000 [1], 1-0, r=1 TDO = 9 (8 bits) COM3: [BB_6] invalid status = 0009 MCLR = 0 No target found. C> |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
An updated version of the MMProg32RPC uMite PIC32 programmer is available for download from http://www.g8jcf.dyndns.org/mmbasic/MMProg32RPC.html This version should be much more stable. Peter The only Konstant is Change |
||||
| Keith W. Senior Member  Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Thank you Peter, I have programmed a chip in 21:58 using your new version, without the error report suffered(falsely)with the previous version regarding a Checksum error. Will you please indicate of any possible ability to program a range of chip types? I am hoping at least PIC32MX170's in anticipation of migrating to them. And have you achieved any further developments with use of Plugin? Could you squeeze the complete 32 bit program sequence into the 1K Plugin space and with what speed gain? Further: As a Maximite clocks at 80 MHz vs 40 MHz for a Micromite, if used as a programmer does it offer a useful speed gain? I think that the Maximite MMBasic is now close to that for a Micromite in the functions required for your program. GeoffG has indicated that he may consider adding the Plugin function to the Maximite. Many (on this forum probably most) of us have Maximites already. Regards, Keith. |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Keith Very glad to hear that it's all working. Following up from your report, I tinkered with the code a little after tracking down the source of those erroneous messages, and also changed the programmer to always use the ROW_PROGRAM PE function which seems to give reliable programming results. I've put in all the code required to program the entire range of PIC32 chips including MZ. I personally have flashed PIC32MX170F256B chips numerous times (this is my standard uMite chip), and the original PIC32MX150F128B chips as well. Re Maximites, the MMBasic code executes so slowly relative to the timing constraints of the PIC32 that I'm pretty sure that if one could run the code on the Maximite that it would run correctly - I don't have a Maximite so I don't know what the language difference's might be. Re Plugin's, see the original topic re 4.6 http://www.thebackshed.com/forum/forum_posts.asp?TID=6942&PN =2&TPN=6 Take care Peter The only Konstant is Change |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
good morning, afternoon, or evening (as the case may be) to all. attached is a zip archive containing a modified version of pic32prog that will operate with a micromite programmed as a 4-wire JTAG programmer. there are a couple of small issues still present, but these do not prevent the programming of an mx150 with the micromite (or any other) .hex file. 2014-10-07_043037_pic32prog_bitbang_JTAG_version_BETA_01.zip the archive contains the following files: * adapter-bitbang.c source code for the 'bitbang' interface. this is the only code that has been altered from the r98 release of pic32prog on the code.google.com site. note that this version will, at this time, only compile for windows. someone might care to perform the translations to achieve dual windows and linux source compatibility * command.bat a batch file convenient for testing. opens a command prompt in the current directory. from here programming is carried out with: pic32prog -d COMx mmbasic.hex (where x is the comm port number) * compile.bat recompiles the source using mingw. * COPYING.txt legal requirements for GPL * make-mingw makefile, modified to work with latest mingw * MicroMite JTAG interface v4.bas basic program to be loaded onto the micromite that will be doing the programming. this interprets single-letter commands as per the explanation in adapter-bitbang.c * pic32prog.exe compiled .exe of pic32prog including the adapter-bitbang.c extensions. note that all other functionality is still present and completely unaltered, for example programming using a pickit2/3 * uMite JTAG programmer schematic.jpg schematic for the programmer hardware. not much more that a couple of pic32's: 
the time taken to program micromite basic into an mx150 is approximately 15 minutes, with the PE loaded in the first 20 seconds. note the RxD/TxD LEDs on your usb to serial bridge while programming the actual code - very little time is spent actually transferring data. usinga an arduino pro mini (around $3 on ebay) instead of a micromite would speed up the process considerably. note that a status error is printed at the beginning of programming, and there is a checksum failure at the end. these can both be ignored for the moment. the verify of the last 4-bytes programmed fails because 'code protection' is not being correctly turned off - as indicated by the status error report at the start. this is a problem in the routine serial_execution() that remains to be fixed. fyi, this is what my own setup looks like: 
i would very much appreciate feedback before proceeding any further. plans are, if there is interest, to look at moving from using 4-wire JTAG to 2-wire ICSP, as well as using a non-programmed interface to the target. cheers, rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
is anyone still following this thread? if not, then i'll abandon my efforts. as at the beginning, i still see value in being able to create a micromite using non-programmed hardware, and believe this is an achievable goal. but if no one replies to this thread, i shall take the hint and chuck the towel in. over the last few days i've been trying to rework my LM555 pic32 programmer circuit to allow reading back PGD via the serial port's RxD line. i believe i now have a solution that should work: 
essentially, TxD is now looped back to RxD on the usb-to-serial bridge indirectly, via a resistor. this allows for the characters being echoed back to be modified on the fly. we take the falling edge of the monostable output, and turn it into s shortish negative going pulse (3uS). this, via a diode, inserts one or two zero bits in the middle of the bitstream. but, if PGD is being driven low by the target (after the 3rd clock pulse) then the PNP transistor will already be turned on, which suppresses this negative pulse. so the programming procedure consists of sending TDI, TMS, chr$(255), 4th pulse. TDO will be encoded into the 3rd character returned in the sequence. if it is read back as chr$(255) then TDO = 0 (transistor turned on). if it is a lesser value then TDO = 1 (transistor turned off). experiments with pic32prog and a micromite as JTAG programmer have shown that good throughput can be achieved via a serial port provided one works with (not against) the buffering within the operating system. the OS is happy to buffer up data coming back, so one can stream out data to be written to flash at high speed, then at leisure read out the response. i believe programming in just a few minutes may be possible using a generic serial port bridge. feedback, please? rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3678 |
I'm short of time so only reading. The LM555 looks too complex and too many components for me. If I get a chance I plan to see what I can get into the rather small plugin umite space and if it's enough then move my code there and in that case I suppose under 2 mins to program pretty much anything. John |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
I still read this post when I get the time, and I do have to agree with JohnS that the 555 circuit is a bit too complicated. The only Konstant is Change |
||||
donmck Guru Joined: 09/06/2011 Location: AustraliaPosts: 1310 |
there are a lot of people following this thread. :-) And yes, I agree it has to be simple, no 555 timer. Cheers Don... https://www.32v8.com/d |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
I'm following it too and a lot of it's over my head but it's interesting. I'm going to have a go at using Peter's technique now that I've (recently received) my 170 chips. Greg |
||||
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
Me like Greg, I'm interested but it's too much for me. I'll stick to my Pickit3. Bob |
||||
| Page 26 of 28 |
|||||
 Print this page |
