 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 22 of 28   |
|||||
| Author | Message | ||||
bigmik Guru  Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
Anthony, I couldnt get it to work at all with my USB2 ports of my i7.. There must be something in the timings that `like' my USB3 but hate the USB2 ports.. FWiW I actually fitted a 3k resistor as I had millions of them and only a few 3k3 but I doubt that would make much difference. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| ajkw Senior Member  Joined: 29/06/2011 Location: AustraliaPosts: 290 |
Mick, I got it to work once with one of your boards on the VM Win7, took overnight (I think this was with a 4.7K resistor!). Zonkers board is unresponsive after a seemingly successful update(s). I don't use it that much but I would like to get it going again. I just tried it on Native XP on this box, same speed. ctrl-c and am now back to Ubuntu now. Despite John's suggestion I am off to a Ubuntu VM to play with the Linux version and have a look at the LDD file he mentioned. If I get it going there I may then run it on the host. Next step may be Pci-e Usb 3 card. Cheers, Anthony. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Not working "might" be the resistor. I've moved to a much lower one for direct programing. Try 1K or (as I did) 1K&3K3 = 767. But Anthony's is slow rather than not working and I think using VM is a likely problem. As he has Linux, it makes sense to use it :) I see every reason to avoid VM and none in favour of using a VM. It will inevitably be much slower if it works at all. John |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2948 |
It's in the post John, along with a 28-pin socket in case you needed one! Posted 1st class, so will be with you latest Tuesday (hopefully!) 
WW |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
unfortunately, using the usb flow control lines, the linux/windows programming software is dependant on a data path that is entirely hidden and may vary greatly in length and reliability between machine installations. i suspect this is why it works very well for some people, and very slowly or not at all for others. john: can i possibly persuade you to have a look at the LM555 programmer circuit i suggested earlier? this will allow for up to a 100,000bps flow of PGD bits with extreme reliability. and by 'counting the bits back in' via RxD one can determine exactly when it is ok to read back TDO. assuming a small proportion of TDO reads relative to writes, this should yield around 60 seconds to programming a 32MX150. i have calculated the necessary resistor and capacitor values, which are determined entirely by the minimum timing resistor value of 1k for the LM555. while not as simple to construct as the single resistor method, this solution should be well within the reach for most folks to build. rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Thanks! |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Except when using a VM, the vast bulk of the paths for USB packets are the same for anyone on Windows or anyone on Linux. Only the drivers (generally for the motherboard) may change a little from one person to another. I've not tried a VM and plan not to as it can only slow things and add more chances for problems. What can be a problem is the delay introduced by the 3K3 resistor (and shape of the waveform) but as I've no suitable tools (storage DSO / whatever) I don't see a way to see how good or bad the signals typically are. Maybe someone can look? The snag with it as I saw it was that it didn't look like it would work with an arbitrary delay (of many ms) inserted between signals/chars. Would someone like Anthony be able to build and use the 555 circuit? It looks beyond what I would normally attempt, not that I own any 555s anyway. I liked the 3K3 resistor because it doesn't even need solder plus I guess a seller of umite etc boards might be happy to throw in a resistor and maybe stock the FT232R board if that helps. Would they build a 555 with its other components... I'm not totally averse to looking at it but I'd rather first get a umite programming another umite (or indeed any mix of mites programming mites), so that at worst a user just needs to program one mite (slowly) and can then use it to program all the others quickly. John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
assuming you count out/in PGD bits, then you can simply wait for the in/out count to match, before inserting the desired delay in your code. i'm assuming that there are only a few places where it is necessary to wait, apart from when reading TDO and entering ICSP mode? when programming rows of data, do you have to pause for a fixed time, or can poll for a 'completed' bit? i do agree that the single resistor method is simple and elegant, however it does seem to be causing some folks problems. if these can be overcome then fine, but i don't see how this may be achieved for everyone - there are so many variables involved. btw, the component values for 3uS, 6uS, 9uS pulse lengths are: 1) R = 1k, C=5n6 for the LM555 timing components 2) R = 150k, C = 5n6 for both PGC delay networks 3) diodes can both be 1n4148 or any other small signal variety 4) resistor at pin 3 can be 1k the choice of 150k/5n6 yields clock pulses for pin 2 of the LM555 and PGC of about 1uS, which should keep everything happy. one then just sends out chr$(252) [3uS] to clock a '1' into PGD, chr$(0) [9uS] to clock in a '0'. the 3rd and 4th clocks can be achieved with either, but i'd be inclined to use chr$(240) which corresponds to a 5mS pulse. rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
There are lots of places where waits are needed, depending on such as Pracc bit, but for now ignore those. I really don't see how your 555 hooks up in an overall circuit for both PC and ICSP. Well, I think I do but it looks to need lots and lots of RTT (round trip time) delays such that it won't matter what speed uart Tx is but worse I don't see how PGD is to be read in by the PC in any sort of fast but co-ordinated way. If it's connected to a modem status line then 2 USB packets are needed to sample it (one out to the USB serial device, one back that has the bit). So you'd send a byte over Tx (which is actually done using a USB packet), then try to read PGD but by the time the 2 USB packets have happened for that (so 3 packets so far) it's dog slow isn't it? You can't send any more over Tx till you've got that bit back so it all sits idle while USB packets fly around. A further complication is that you don't know when the byte went out over Tx so you don't know when to start sending the packets to read the modem line to get PGD. It's likely that just assuming a Tx has happened by the time the next packet goes out will be true but it feels unsafe. Say it is safe, how's it any better than what I do now? How's it better than the current way? I don't understand how PGD is driven out of the PC (to send TMS and TDI). How many bytes (and what values) would be sent over Tx per PGD bit going towards the PIC32? John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
when you want to send out a bit to PGD, send to the uart a chr$(252) for '1' or a chr$(0) for '0'. the LM555 and associated components turns the resulting single pulse on TxD back into PGC and PGD. this is the core concept, that both PGC and PGD are recreated from a single pulse appearing on TxD. the value of PGD (0/1) is determined by the length of the pulse (9uS/3uS). the comm port needs to be set to 1Mbps, 8 bits, no parity for these times and the component values i have give. TxD and RxD are connected together, so you can count these pulses back in using an isr in your software, in just the same way any other comms package does. the only difference is that you have little interest in the characters read back in beyond keeping a close count on the number of characters. as you send out characters on TxD, count them. as you receive back characters on RxD, count them. PGD and DSR are connected together. whenever you want to read the value (of TDO) on PGD you need to (1) wait until Rx count = Tx count, (2) read the state of DSR. as DSR is a standard control line, you should not need to use any device-specific code. whenever you want to insert a timed delay, (1) wait until Rx count = Tx count, then (2) delay for however long is desired. the overall delay will never be shorter, but may be slightly longer. the overall speed gain is when sending out long streams of PGD bits without any need to read back in TDO. the maximum speed when doing this is 100,000 bits per second. the whole process is fully interlocked, and will achieve maximum speed supported by the comm port drivers whenever it can. it will also work with any usb to serial bridge, or even a real port. rob :-) |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
Anthony, When I tested Johns prog I powered MuP off the FTD232 board (the 5V comes straight from the USB port and in the case of USB3 can source 1.5A so no issue there.. I also made sure the wires were separated and not crossing over each other (as best I could) and the wires were fairly short 20cm ones. I might try it all again with my AMD hex core box.. John, Is the latest Version to try the one that is 360,867 in size (dated 17-Aug-14 but that could be the date I downloaded that one)? Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
Mick & John, I have been testing some more today, I have tried different power sources, different resistors, have separated the leads and tried others as well. I have also tried some capacitors between gnd and pgc/pcd which seen to have had little effect on speed but a large tendency to cause errors (with the the resultant XferInstruction: cv=0). I then tried a LED between gnd/pgc/pcd as well. I could see the pulses. This got me to dust the CRO off and I measured a clock cycle of ~2ms high 2ms low. The Hz setting on the DMM gave 200 - 220Hz. I have googled USB flow control lines, slow USB and the like but not found anything there to date. I have also tried another computer. This kind of leaves the FTDI board. I do have another FTDI device with leads but it does not have all the control lines so I can't test it. I have got John's linux program to run on a VM, about the only thing is to try it on the host but I am not holding my breath. Anthony. |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
Hi Anthony, I will complete my range of tests I intend to do today: i7 USB3 i7 USB2 AMD USB3 AMD USB2 Then I will send you my unit for you to try.. Yours came in the same batch so I cant see why it would be any different.. Regards, Mick EDIT*** I do notice that this time it IS running slower than before (just hit 80% at the 18 minute mark) I have used 30cm wires this time.. I will erase and try the 20cm again when it finishes. Although this is still not really slow program times considering the method. Mick EDIT 2 **** Had my first failure on the i7 box after the 90% mark had a whole heap of PE_getresponse: CV = 0 errors Mik Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
Lads, Tests so far (reverted to my 20cm cables) i7 USB3 finished (and verified with MPLAB IPE and PicKit3) 18min 37sec i7 USB2 Could not get it to work, continuous errors of something like USB not detected even after a reinstall of the driver AMD USB3 now programming but at about 1/6 the speed of the i7 (12sec per dot compared to about 2sec) expect an update in 90mins unless it fails. Summing that up I suspect the USB3 is NOT the reason the i7 is so fast as I am using a `native' USB3 on the AMD box.. I can get fast USB speeds out of the AMD (cant quote differences till tests are finished. The AMD box is running win7 PRO 64bit the i7 is win8.1 Pro 64bit. Mick PS. The speed on the i7 is definitely slower than my previous tests, I wonder if different pic32 chips behave differently as well. Mick EDIT*** Hmm, the AMD box has just brought up a windows warning that I have had a power surge on a USB HUB, never seen that message before and I dont see why that would be the case as surely I am not drawing more than 100mA or so.. maybe 150mA.. I can measure this but it is still going at 20% after 16min 30sec Mik Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
Lads, Well, it finally finished. It took a massive 3hrs, 34minutes and 40 seconds to program on my AMD hex core PC using USB3 (native not plug in addon board) But I did a verify with PicKit3 and MPLAB IPE and it did verify perfectly. Not sure what it is saying... similar PCs but one is AMD the other i7 but a 12 fold increase in programming time. Anthony do you want my module to try? Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
Mick, Your results seem to suggest it is the PC and not the FTDI board that produce the variance so I am not sure that trying yours is warranted. Thanks for the offer. I have the MUP2 I just got being updated now, I hope it works but I had to try. I had no luck with Zonkers board. I may this week buy a USB3 Pci-e card and try that. One thing I have noticed, when programming, after the PE loads the first 15% of "programming main flash" is almost done immediately and then begins the dot every 23 seconds. Is that similar on yours? Cheers, Anthony. |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
Anthony, Yes, the first 20% virtually flies through then it starts to bog down a bit.. The i7 was doing 1 dot every 2 seconds, the AMD EVERY 12 seconds. That was in early stages.. I didnt time them later on. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
The reason for the fast parts is that the chip has been erased and the hex has 0xff bytes. I can't say often enough not to use a VM. I expect it will always be slower. I'm on 32-bit Linux and (when I have to be) 64-bit Win7Pro. I reckon my wires are about 15cm. My resistor is at the target PIC32 end as it was easier to poke it into the connector there. When I get a bit more spare time I'll make the new variant (the one that programs in about 40 secs) work so that a 'mite can program another 'mite. And then go back to Windows and make it work there. You'll still have to get one 'mite programmed with it using the USB way. If POKE worked such that you could then CALL the result I suppose all this could be avoided by having the 'mite itself load the programming software and call into it. John |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
Tonight's trial is running at 9 sec per dot, that is a lot better than 23+ 😄 I have a second resistor at the target and have booted the computer off a Ubuntu 32 bit DVD. I'm not yet sure which is responsible for this improvement but things are looking better. |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
MUP2 is back and done in under 3 hours. I have now gone to a 1k resistor at the target with Zonkers board but it is still 9 sec a dot. |
||||
| Page 22 of 28 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
