 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 : MMflash - Flashing MM’s made easy
  Page 2 of 3   |
|||||
| Author | Message | ||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6270 |
No need for this step. The inf file is not written to until you close the program but all the default values are created immediately at startup whenever the inf file is not found. If Rob's problem turns out to be uM timing, I will have to add the ability to test the timing. I gave it some thought overnight and think I have a cunning way to measure the clock without any other connection to the mite. This is all new to most of us and there are a lot of things that can go wrong. Once a few more users have problems that get solved, we will have a useful knowledge base. Jim VK7JH MMedit |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9593 |
Haha - well, go to YT and type in "Dancing girls" - about six million videos to choose from - take your pick. 
[Quote=TassyJim]Can you try this replacement exe. It is MMflashA.exe and put it in the same folder as the others. I have made some changes to the compiler options. 2016-01-24_064519_MMflashA.zip Jim Nope, same crash at the same point. @ all other members - Is anyone else seeing this? It might just be something weird with my machine. I will try this out on another machine. Smoke makes things work. When the smoke gets out, it stops! |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
Just looked at Peter's programming times again. Note the 3min 47secs he got using an FTDI232 USB/serial converter. Mine's also a "genuine??" FTDI232 and I got 3min 46secs on the 10 yr old XP notepad I'm using - one second difference - sure seems that way Peter! Greg |
||||
| Bizzie Senior Member  Joined: 06/07/2014 Location: AustraliaPosts: 192 |
Hi all, Thought I would report my progress! I personally have not been able to program a 170 28 pinner when connected to Mick's backpack 170 board for the target chip carrier. I built up one of Mick's MuP boards and all is well. I have also updated two of my CGMicroboard2B's with no problems. BUT I am having problems with a setup using a 40 pin ZIF socket. I can talk with the MM+ using TeraTerm so believe the capacitor on pin 19/20 is OK and I have the other pins correct. When I run MMflashA I get the following :- Programming slave device Connected to Master at 38400 Connected to Master at 115200 Baud Rate changed to 115200 RUN Programmer for Microchip PIC32 microcontrollers, Version 2.0.186 Copyright: (C) 2011-2015 Serge Vakulenko (ascii ICSP coded by Robert Rozee) Adapter: . OK1 OK2 - ascii ICSP v1M Processor: MX170F256B Flash memory: 256 kbytes Boot memory: 3 kbytes Data: 491700 bytes total TDI/TMS pairs sent = 151 pairs total TDO bits received = 72 bits total ascii codes sent = 73 total ascii codes recv = 27 maximum continuous write = 24 chars O/S serial writes = 9 O/S serial reads (data) = 3 O/S serial reads (sync) = 0 XferFastData count = 0 10mS delays (E/X/R) = 0/0/0 elapsed programming time = 0m 00s Error code: 1 Programming completed in 0.985 seconds Connected to Master at 115200 OPTION BAUDRATE 38400 ààà Port Speed changed back to 38400 What does Error code 1 mean? Rob White |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6270 |
@Bizzie, read robert.rozee's comments above. Your setup is failing when it tries to send a large amount of data. This could be due to the timing of the Master and running OPTION CLOCKTRIM xx where I would start with -4. This option resets when you apply power to the chip so it has to remain powered up during the process. I intend to add a CLOCKTRIM setting to MMflash but for now you could try my new MMTimeLord to see what CLOCKTRIM setting you need for precise timing. Another cause of the problem could be stray capacitance on the control pins or a wrong value for the pullup resistor on MCLR. I use 10k. Error Code 1 is not important. You get better information from the detailed report. If you have been able to program some chips in some circuits but not others, it points to something in the circuit, but could still be timing. Jim VK7JH MMedit |
||||
| Bizzie Senior Member Joined: 06/07/2014 Location: AustraliaPosts: 192 |
Well thanks to both Jim and Robert I now have my system working :- Programming slave device Connected to Master at 115200 RUN Programmer for Microchip PIC32 microcontrollers, Version 2.0.186 Copyright: (C) 2011-2015 Serge Vakulenko (ascii ICSP coded by Robert Rozee) Adapter: . OK1 OK2 - ascii ICSP v1M Processor: MX170F256B Flash memory: 256 kbytes Boot memory: 3 kbytes Data: 257992 bytes Erase: (90mS) done Loading PE: 1 2 3 4 (LDR) 5 6 7a (PE) 7b 8 v0301 Program flash: ################################################# done Program boot: ####### done Verify flash: ################################################ done Verify boot: ####### done Program rate: 2138 bytes per second total TDI/TMS pairs sent = 3145852 pairs total TDO bits received = 499032 bits total ascii codes sent = 989125 total ascii codes recv = 171567 maximum continuous write = 452 chars O/S serial writes = 95710 O/S serial reads (data) = 15603 O/S serial reads (sync) = 10 XferFastData count = 57829 10mS delays (E/X/R) = 9/0/0 elapsed programming time = 2m 03s Success! Programming completed in 122.934 seconds Turned out to be "stray capacitance" I had the serial wires looped around the short lead to the ZIF socket! Separated them and away it went. Thanks again Rob Rob White |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6270 |
Good news Rob. All the testing and reporting your progress will help others. Thanks for being persistent. Jim VK7JH MMedit |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2437 |
i would not expect to see such results. the 'original' specs i arrived at are for PGC, PGD and MCLR to all be driven with open-collector outputs, with 3k3 pullup resistors to 3v3 for PGC and PGD at the programmer end, and 10k to 3v3 at the target end. settling times used for signal changes are 1uS, that is: change PGD, wait 1uS, pulse PGC for 1uS, chagne PGD to next value, wait 1uS, pulse PGC for 1uS, etc. under these condistions a little stray capacitance should have no effect, while the 1uS delays will introduce no material increase to programming times. questions: does matherp's Cfunction retain these 1uS delays? are PGD and PGC driven hard to high/low? or are they implemented as open-collector with reliance on the internal pullups within the micromite running the Cfunction? relying upon the micromite's internal pullups is unlikely to produce satisfactory results. cheers, rob :-) |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
In my version with the pic16f1455 i set the PGC/PGD pins to output and drive them high/low and don't use 1uS delays, just as fast as possible. Using the internal pullups did not work reliable at all. Microblocks. Build with logic. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10251 |
Driven high and low. There is a short wait state (2 NOP) before the read which proved necessary on the MM+ at 100MHz but wasn't required on the uM2. Given that the factor limiting speed is the USB I/F to the PC it would probably make no difference to programming times to put lots of waits in but I didn't find it necessary |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4038 |
I expect you have quite short PCB traces with decent characteristics so signals are great. I'm guessing that pic16 isn't very fast. What sort of max speed is it able to achieve on PGC/PGD? Driving PGC/PGD from a Raspberry Pi I needed short delays (it will swing signals at about 22MHz if you leave the delays out - thus not meeting the PIC32 datasheet specs). John |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I had my prototype on a pcb prototype board and used about 10cm long leads. It is connected to Mick's MUP and has console and ICP lines connected to allow both functions through the same PIC USB-Serial. 
I did not measure the speed of the PGC/PGD pins but the programming speed was very good. Baudrate is irrelevant when using USB directly. [code] C:\Users\mail\Dropbox\Micro Blocks\Projects\BreadBoard\U2SP5\Software\pic32prog> pic32prog -d ascii:com10 MMV4.7B32.hex Programmer for Microchip PIC32 microcontrollers, Version 2.0.174 Copyright: (C) 2011-2015 Serge Vakulenko (ascii ICSP coded by Robert Rozee) Adapter: .. OK1 OK2 - ascii ICSP v1E Processor: MX170F256B Flash memory: 256 kbytes Boot memory: 3 kbytes Data: 258692 bytes Erase: (110mS) done Loading PE: 1 2 3 4 (LDR) 5 6 7a (PE) 7b 8 v0301 Program flash: ################################################## done Program boot: ####### done Verify flash: ################################################# done Verify boot: ####### done Program rate: 7595 bytes per second total TDI/TMS pairs sent = 3723775 pairs total TDO bits received = 957768 bits total ascii codes sent = 1190023 total ascii codes recv = 329262 maximum continuous write = 452 chars O/S serial writes = 111528 O/S serial reads (data) = 29940 O/S serial reads (sync) = 10 XferFastData count = 58902 10mS delays (E/X/R) = 11/0/0 elapsed programming time = 0m 35s [/code] Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4038 |
Thanks. I was hoping you had some idea/estimate of the kind of I/O speed the pic16 actually achieves (with whatever clock/xtal it has) because as I mentioned I needed delays with the (much faster I expect) RPi. As you say it makes little difference overall (well, it does for the RPi since without the delays you never get a programmed PIC32). John |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I used the internal oscillator OSCCON = 0x7C; // PLL enabled, 3x, 16MHz internal osc, SCS external and the fastest pin would be the PGC. To get the best results i did not use function/subroutines but made some defines. [code] #define PGC_INACTIVE TRISAbits.TRISA4 = 1 #define PGC_OUTPUT TRISAbits.TRISA4 = 0 #define PGC_LOW LATAbits.LATA4 = 0 #define PGC_HIGH LATAbits.LATA4 = 1 #define PGC_PULSE PGC_HIGH;PGC_LOW [/code] A pulse would then be [code] LATAbits.LATA4 = 1; LATAbits.LATA4 = 0; [/code] Not sure about how long those instructions will take but with a 16Mhz clock i guess it is not long. I do not have a scope available at the moment, lend it to a friend. :) Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4038 |
No worries. Don't spend time on it - I just hoped you knew. John |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
If i had to make a guess then it is running at 12 instructions per uSec. (16Mhz x3 = 48Mhz / 4 cycles per instruction) So the width of the pulse would be 1/12 of a microsecond. Microblocks. Build with logic. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2437 |
#rant on an enormous amount of thought, time, and effort (approximately 1 year) went into developing the ascii ICSP extensions to pic32prog and the associated hardware, in order to arrive at a production quality end-product. this included a detailed signal analysis on the PGC and PGD lines. there were quite severe hardware compromises made along the way, and these were in turn mitigated in software - throughout i was conscious of requests to keep the hardware side of things as minimalist as possible. those 1uS delays are quite essential to ensure signal integrity under the widest possible range of hardware hookups. while the PicKit2 has the luxury of dual mosfet drivers into each line (providing a very low source impedance), i was working with a paltry 20mA at best when driving those lines with a 328p or PIC. please do follow the overall design specs. they weren't just 'pulled out of a hat', there was much thought and calculation behind them, along with a great deal of beta testing by myself and others. the essential portions of the design here include: the alllowance for 1mS settling times on PGC and PGD, as well as the decision to have the programmer control the power supply to the target PIC32. #rant off cheers, rob :-) |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
The way i read the source was that the 328p used a Hi-Z and a pullup to get high and low signals. My assumption was that the 1 microsecond delay was to compensate for this specific use. In the PIC i set the pin as an output port and drive both high and low. In my test i used long/short cables, multiple of pcb's with a pic32 on it and they all seemed to work just fine. If i am incorrect please let me know and i will add the 1 microsecond delay to prevent failure. My decision to not power the target pic32 has to do with the numerous broken pic32's i have seen caused by people who by accident had a powered pcb and choose to power the pic from the programmer (pickit3). I have run a makerspace for a few years and that is one of the common mistakes people make. I personally think that in the case of my USB/SERIAL and programmer combination that functionality is not needed. I am planning a small pic32 programmer board with a zif socket and for that version controlling the power is great. Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4038 |
The datasheet seems to say min hi&lo times are each 40ns but period min 100ns. I was perhaps not originally meeting those, but also with flying leads would have been inviting trouble, so I added small delays and all worked. (I would not expect 1us to be needed, though with USB-serial it's probably harmless. Not that the RPi one uses USB-serial.) I suppose there's a time constant, too, which is ignorable with delays! (I don't recall what pullups etc I had, if any, and my notes are not to hand.) Sorry everyone - wasn't meaning there to be any rants. John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2437 |
the 1uS was selected to ensure signal integrity under the widest possible range of hardware hookups, with the use of 3k3 pullups and open collector outputs just one of the design features being compensated for. also of consideration was the observation these delays introduced no material impact on overall programming time. 10uS of delays per TDI/TMS pair x 3,200,00 pairs = 32 seconds of cumulative delay spread evenly throughout programming - this is well below the best achievable programing times. the lack of impact was borne out in beta testing. even with a pic16f1455 solution, the cumulative delay is still only on par with the best-reported programming times. as an experiment, i'd suggest trying various delay lengths (ranging from 0uS up to 1uS) and compare the resulting overall programming times. cheers, rob :-) |
||||
| Page 2 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
