 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 20 of 28   |
|||||
| Author | Message | ||||
| robert.rozee Guru  Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
it is not so much the rate, but the slope of the edges on the clock pulses. the clock rate could be at just 100Hz and still have fast edges that could migrate across wires. the programmer John is using (an MX150?) itself is only capable of driving 10mA, which is far less than a buffer / line driver (74LV1T45) can achieve. 10mA translates to an effective output impedance of a few hundred owns. a few capacitors are a quick and cheap experiment to try. rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
rob - thanks for that article (am busy reading it) Keith - I posted about transitions on PGC. Your code would be pin(clk) = 0 (or = 1). I am as I posted calling functions, with delays as well, for the equivalent thing (on PGC or PGD or indeed MCLR). Using an 80MHz PIC32 (*) to do the programming it was essential to slow it down and to do that in a reliable manner and I said so in some detail in my previous post. By definition, it won't slow down chip-created signal edges (**) etc nor avoid crosstalk etc, so over to the article rob pointed out... (*) it happens to be a 440F256H; I am highly tempted to try either an RPi or an Allwinner chip (**) some uC chips (e.g. Allwinner & STM32) allow the rise times in effect to be selected but I believe the PIC32 does not John |
||||
| ajkw Senior Member  Joined: 29/06/2011 Location: AustraliaPosts: 290 |
John, I am using 2014-08-15_220827_ftdipic32.zip with a MircoMite on BigMik's MUP board. At the moment I seem to have it hooked up and programming away I get regular (about once a second) "XferInstruction: cv = 0" messages. (sometimes cv = other numbers like 600,400,800000 etc) Is it working? Other users seem to report a progress % done. I don't have that. I have also now seen a occasional error message but then the "Xfer.." messages continue. Is this a problem? Anthony. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
It's gone wrong, sorry. (Harmless but annoying.) The error detection and recovery is rubbish as yet, very sorry. Kill it (harmless, it's all low voltage safe programming), check wiring / resistor. Restart. If it keeps happening it's something like 2 wires crossed or GND missing. (Or a previously unreported problem, please don't let it be that!) Did it at least identify the PIC32 type (I suppose as 150F...)? It should be along the lines of the screen shots here John |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
John, I had already killed it and could tell it had done nothing. Tests so far seems to suggest I have a problem with CTS, with it not connected I get the following C:\>ftdipic32 -t PIC32MX150F128B setting MCLR HI MCLR LO MCHP sent DATA_IDCODE -> 0x00000000 PIC32MX150F128B RAM 0 8000, ROM 1d000000 20000, BOOT 1fc00000 c00 DEVID Version (chip Revision) 0 MCHP_STATUS -> 0x00 EnterSerialExecutionMode ...^C C:\> and when connected I get C:\>ftdipic32 -t PIC32MX150F128B setting MCLR HI MCLR LO MCHP sent DATA_IDCODE -> 0xffffffff Unknown DEVICE ID - Disconnected? Exiting C:\> I have soldered a resistor (4.7K) across the DTR-DSR pins on the back of the FTDI board, could the value be bad or have I got it in the wrong place?? |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
You shouldn't use -t unless Mchp release a newer PIC32 unknown by the program. I'll add a note to the howto about that. The program knows all the current chips. I've only tried a 3K3, no idea if 4K7 is too big. From what others have posted it'll delay the signal more. I guess (?) it may reduce the voltage too. Did you set the board for 3V3? Also, you need the signals connected as in the howto. (That leaves DTR only connected via the added resistor.) Do not connect 3V3 from the FTDI or - if using an ICSP connector - PGM i.e. pin 6. It ends up reading PGD directly via DSR and driving PGD via DTR through the resistor. John |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
John, It is working now, I had the resistor wrong. Mine is going at just under 8 seconds per dot. Virtual Win 7 on a Ubuntu host, USB2. Perhaps I could get the Linux version off you and see if that is faster? Many thanks, Anthony. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Wow, I'm quite impressed it works at all via a VM! I built the EXE with static libs but didn't get around to that for the Linux version. So, you'll need some (ldd file will tell you which). I basically installed libftdi or some such name - whatever the dev one is (I'm not on Ubuntu), something like libftdi-dev and you'll need libusb-dev or similar. Here's the linux version 2014-09-03_124032_ftdipic32_linux32.zip You'll need a udev rule or else run as root so it can grab the USB device (which otherwise is -correctly- treated as a tty-type device). John |
||||
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Can the "collective" please suggest how to improve the performance of the following piece of code. As it stands this piece of code takes about 47mS to execute (with CPU 48). I have tried eliminating the "SETPIN PGD,DIN" statements but then the sub doesn't work ! '=========================================================== ===== ' 'To quickly send 32 bits of data in/out of the device. ' 'Section 6.4, Page 16 XferFastData Pseudo Operation, Page 16, Fig 6-9 ' 'Args In: ' CommandLo & CommandHi is the Command to be executed split into 16 bit chunks ' We need this function because MMBasic does not support 32 Integers ' 'Results: ' Returns 32 bit result in Hi16 and Lo16 ' ' SUB XferFastData(CommandHI, CommandLo, H16, L16) LOCAL I,TDO,K,L,M 'TMS Header 100 'TDI=0, TMS=1, TDO=x SETPIN PGD,DOUT PIN(PGD)=0:PULSE CLK,.01 'TDI=0 PIN(PGD)=1:PULSE CLK,.01 'TMS=1 SETPIN PGD,DIN PULSE CLK,.01 PULSE ClK,.01 'TDO=x 'TDI=0, TMS=0, TDO=x SETPIN PGD,DOUT PIN(PGD)=0:PULSE CLK,.01 'TDI=0 PIN(PGD)=0:PULSE CLK,.01 'TMS=0 SETPIN PGD,DIN PULSE CLK,.01 PULSE ClK,.01 'TDO=x 'TDI=0, TMS=0, TDO=oPrAcc SETPIN PGD,DOUT PIN(PGD)=0:PULSE CLK,.01 'TDI=0 PIN(PGD)=0:PULSE CLK,.01 'TMS=0 SETPIN PGD,DIN: PULSE CLK,.01 PULSE ClK,.01 'TDO=x 'PrAcc 'TDI=0, TMS=0, TDO=oLSB SETPIN PGD,DOUT PIN(PGD)=0:PULSE CLK,.01 'TDI=0 PIN(PGD)=0:PULSE CLK,.01 'TMS=0 SETPIN PGD,DIN PULSE CLK,.01 PIN(CLK)=&H1 TDO=PIN(PGD) PIN(CLK)=&H0 'TDO Contains result of last operation 'Send 31 bits of Data with TMS=0 'Clock Out CommandLo<b0-b15>, ie <0>...<15> M=&H1 FOR K=0 TO 14 L=CommandLo AND M 'L=CommandLo<K> M=M*&H2 'Next LSBit mask 'TDI=CommandLo<K>, TMS=0, I=oLSB<1+K> SETPIN PGD,DOUT PIN(PGD)=L:PULSE CLK,.01 PIN(PGD)=&H0:PULSE CLK,.01 SETPIN PGD,DIN:PULSE CLK,.01 PIN(CLK)=&H1 I=PIN(PGD) PIN(CLK)=&H0 I=I*M 'Shift I Left to <K+1> position TDO=TDO OR I 'Or in the new TDO bot NEXT K 'We now have 16 bits of TDO, so update output L16 L16=TDO 'Clock Out <15> ie CommandLo<15> out L=CommandLo AND &H8000 'L=CommandLo<15> 'TDO = Clock(L, 0) 'TDI=CommandLo<15>, TMS=0, TDO=oLSB<16> SETPIN PGD,DOUT PIN(PGD)=L:PULSE CLK,.01 PIN(PGD)=0:PULSE CLK,.01 SETPIN PGD,DIN PULSE CLK,.01 PIN(CLK)=&H1 TDO=PIN(PGD) PIN(CLK)=&H0 'Clock Out <b16>...<B30>, ie CommandHi<b0-b14> M=&H1 FOR K=0 TO 14 L=CommandHi AND M 'L=CommandHi<K> M=M*&H2 'Next LSBit mask SETPIN PGD,DOUT PIN(PGD)=L:PULSE CLK,.01 PIN(PGD)=&H0:PULSE CLK,.01 SETPIN PGD,DIN:PULSE CLK,.01 PIN(CLK)=&H1 I=PIN(PGD) PIN(CLK)=&H0 I=I*M 'Shift I left to <K+1> position TDO=TDO OR I 'Or in the new TDO bot NEXT K 'We now have 16 bits of TDO, so update output Hi H16=TDO 'Clock <b31> out, ie CommandHi<15> L=CommandHi AND &H8000 'L=CommandHi<15> 'TDI=CommandHi<15>, TMS=1, TDO=x SETPIN PGD,DOUT PIN(PGD)=L:PULSE CLK,.01 PIN(PGD)=&H1:PULSE CLK,.01 SETPIN PGD,DIN:PULSE CLK,.01 PULSE CLK,.01 'TMS Footer 10 'TDI=0, TMS=1, TDO=x SETPIN PGD,DOUT PIN(PGD)=&H0:PULSE CLK,.01 PIN(PGD)=&H1:PULSE CLK,.01 SETPIN PGD,DIN:PULSE CLK,.01 PULSE CLK,.01 'TDI=0, TMS=0, TDO=x SETPIN PGD,DOUT PIN(PGD)=&H0:PULSE CLK,.01 PIN(PGD)=&H0:PULSE CLK,.01 SETPIN PGD,DIN:PULSE CLK,.01 PULSE CLK,.01 END SUB Very Many thanks Peter The only Konstant is Change |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
by my reckoning, you need to read TDO before the 4th clock pulse is initiated, as at some indeterminate time after the leading edge of the 4th clock pulse TDO will become invalid. you currently have: SETPIN PGD,DOUT PIN(PGD)=0:PULSE CLK,.01 'TDI=0 PIN(PGD)=0:PULSE CLK,.01 'TMS=0 SETPIN PGD,DIN PULSE CLK,.01 PIN(CLK)=&H1 TDO=PIN(PGD) PIN(CLK)=&H0 i believe you need: SETPIN PGD,DOUT PIN(PGD)=0:PULSE CLK,.01 'TDI=0 PIN(PGD)=0:PULSE CLK,.01 'TMS=0 SETPIN PGD,DIN PULSE CLK,.01 TDO=PIN(PGD) PULSE CLK,.01 i suspect some folks will strongly disagree with me over this. my belief is based upon figure 5-4 on page 12 of the 61145N datasheet fro microchip. i find the diagram quite unambiguous. btw, you also seem to use "ClK" and "CLK" in different places, which is a tad confusing at first glance. some languages do distinguish between upper and lower case in variable names, i believe MMbasic does not. cheers, rob :-) |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
I think that too much importance is/has been placed on the apparent relation of clock and data. The ambiguity arises because of the varying text in the in the bit blocks of the timing charts. I think you will find that (as in almost all digital devices) that all timing is related to a specific clock edge and associated data settling time and not some indeterminate time after an event. The more text in a bit block, the more the apparent timing is out of kilter. Edge triggering is always used to determine the availability of data one way or the other so there is never any ambiguity. David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
rob, You may well be right about fig 5-4 (I've no definite way to tell, I think). I've tried various versions of my code, your way and not, and they all appear to work as well as each other. (My current code is written on the basis that it IS the falling edges of PGC that matter.) I wish I knew why: 1. each TCK (top waveform) has an arrow on its RISING edge (rather than falling edge) 2. Mchp chose (dashed areas) to show half of a 4-clock then all of a 4-clock period 3. (at bottom left) the legend is pTDO = 1 (I see no 1 - well, I do, but it's in the wrong place!) 4. (in the dashed areas) just 1 black arrow is on a rising edge It's clear to me that Mchp NEED to explain far better. My email to Mchp with doc errors and questions has gone unanswered. John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
i'll do my best to answer :-) 1. the top 4 waveforms, showing TCK, TMS, TDI, TDO are of the 4 lines you would see with a 4-wire JTAG interface. they are there to show you the information that will be encoded into the 2-wire ICSP transaction. with JTAG each transaction occurs over a single TCK pulse, with the data on the 3 signal lines being clocked in/out simultaneously on the single rising edge of TCK. this top section is just there to show you the equivalent JTAG transaction, which it does a poor job at doing. i believe it is safe to ignore this part (as we have no interest in the JTAG side of things). 2 and 3.. the dashed 'half' transaction is confusing. i don't know why they put it there. i am guessing that pTDO and nTDO correspond to "previous TDO" and "next TDO". the pTDO value of '1' doesn't correspond to anything in the top 4 waveforms as you note. all i can think is that someone asked to have a 'previous' transaction added in to show the flow from one transaction to the next, and the graphics person didn't know about the need to update the top 4 waveforms to match. 4. TCK and PGC are very different signals. the 2-wire ICSP standard encodes TMS, TDI and TDO onto a single wire (PGD). TCK is thrown out, and replaced with a completely different clock signal called PGC. the black arrows are there to show you when 'action' happens. as such the 2-wire ICSP interface can be considered as having 8 'points in time' when things may be triggered into happening. these are: (our setup) before anything happens, the user may place TDI data on PGD. this is ok, as PGD starts out being configured as an input. it would also be OK to not put data onto PGD until after the first rising edge if that eases the implementation. #1 first PGC rising edge: beginning of transaction. signals to the 32MX to go into a state where it is ready to receive an instruction; "please start listening for TDI". #2 first PGC falling edge: data on PGD is transferred into the target 32MX and held internally as TDI. a short time after this edge the user may place place TMS data on PGD. #3 second PGC rising edge: "please start listening for TMS". after this edge the user must place TMS data on PGD if not already done so. #4 second PGC falling edge: data on PGD is transferred into the target 32MX and held internally as TMS. #5 third PGC rising edge: before this edge the user should prepare to read PGD. it is highly likely that this rising edge tells the 32MX to reconfigure PGD as an output. #6 third PGC falling edge: on this edge the 32MX loads the value of TDO onto the PGD output. prior to this edge there is no guarantee that PGD reflects the value of TDO. #7 fourth PGC rising edge: signals to the 32MX that the user has finished reading the value of TDO from the PGD pin. after this edge there is no guarantee that PGD reflects the value of TDO. it is highly likely that this rising edge tells the 32MX to reconfigure PGD as an input. #8 fourth PGC falling edge: end of transaction. this may trigger the transfer of TDI and TMS into the tap controller, but what happens from here on doesn't matter too much to us. after this edge we can safely start driving PGD from our end again. --- so, the arrows indicate the transferring of data. first falling edge transfers TDI, second falling edge transfers TMS, fourth rising edge signals we have finished reading TDO. i hope this doesn't confuse things even more - it is 1:20am here and my brain is starting to get a little fuzzy! cheers, rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
i've edited the above post a couple of times, so do reread it if you've only read the emailed (first) version. i think the 8 edges of PGC can be simplified as the following list of 'instructions' to the 32MX: #1 first PGC rising edge: get ready to read TDI #2 first PGC falling edge: transfer TDI data on PGD into 32MX #3 second PGC rising edge: get ready to transfer TMS #4 second PGC falling edge: transfer TMS data on PGD into 32MX #5 third PGC rising edge: reconfigure PGD pin on 32MX as an output #6 third PGC falling edge: load TDO data onto PGD #7 fourth PGC rising edge: reconfigure PGD pin on 32MX as an input #8 fourth PGC falling edge: <end of transaction> cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
rob, Thanks. Yes it makes sense. (Much more detailed than I expected but can't hurt.) Sorry to keep you up! I think the delay(s) I need (in the 80MHz PIC32 as programmer, with 150F128 as target) must relate to time delay over the 3K3 resistor. When I have a chunk of free time I'll dig out soldering iron etc and make some short wires I can patch with 100R and small cap and generally mess with e.g. to try bidirectional PGD (so no 3K3 resistor). Simply can't try this stuff till I get more hardware bits n pieces. (The central code (for the 4 phases) is anything but straight-line, executes LOTS of instructions, yet still needs delay(s). However, my current wiring is long and PGD/PGC run alongside each other, exactly as they shouldn't.) It's not a disaster, even with delays the PIC32 can flash a umite in 68 secs :) John |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@RR Where I need TDO, I use 'PrAcc 'TDO = Clock(0, 0) 'TDI=0, TMS=0, TDO=oLSB SETPIN PGD,DOUT PIN(PGD)=0:PULSE CLK,.01 PIN(PGD)=0:PULSE CLK,.01 SETPIN PGD,DIN:PULSE CLK,.01 PIN(CLK)=&H1 TDO=PIN(PGD) PIN(CLK)=&H0 As per Fig 6-6 and others, TDO is read out on the rising edge of PGEC, hence PULSE CLK,.01 'This is the 3rd PGEC where "nothing" appears to happen PIN(CLK)=1 'Rising edge to clock the internal shift register TDO onto PGD out TDO=PIN(PGD) 'Read the state of PGD PIN(CLK)=0 'Complete the clock pulse I'm pretty sure I tried PULSE CLK,.01 TDO=PIN(PGD) PULSE CLK,.01 where I don't need TDO, eg in the TMS Header I use 'TMS Header 100 'TDO = Clock(0, 1) 'TDI=0, TMS=1, TDO=x SETPIN PGD,DOUT PIN(PGD)=0:PULSE CLK,.01:PIN(PGD)=1:PULSE CLK,.01 SETPIN PGD,DIN PULSE CLK,.01 PULSE CLK,.01 What I want to know is a) How to make these execute more quickly b) Why if I remove the 'SETPIN PGD,DIN" statement from the second case, it doesn't work. I have fully working code, now I need to optimise it to make it execute more quickly and hence make programming a more realistic time proposition. Thanks for the suggestions @Mobi, I agree with you re edge triggering, what is the point of having a clock signal if there is arbitrariness about exactly when something should happen ? There may be factors such as parasitic capacitance/lack of current-drive which places an upper limit on how fast one can drive the clock signal, but at the speeds we're working at with the PIC32MX those effects should be unimportant. Mind you I'm not a silicon designer/fabricator so perhaps if there is someone who is they could enlighten us ? Peter PS MMBasic like most Basics is case insensitive (thank goodness !) The only Konstant is Change |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
The article (posted before) might help. In MMBasic the pulses will be slow but the rising & falling edges can be fast. Those can induce signals (crosstalk). I think that's a potential issue. I suppose there's also a risk of any of: reflections, overshoot, ringing if I'm using the right terms LOL I like the idea of 100R series and a small cap, plus short leads that do not run next each other so will try it "soon". I think I worked out the 47ms routine is about 467 MM statements so about 100us per stmt. I recall Geoff or someone mentioning speed of a maximite but not what it was. I suppose a umite is about half whatever it was. I've not tried 2-phase ICSP but ought to be 2x speed roughly... John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
it would be desirable to try and put all your delays in one place if you can, right down in the code that manipulates PGC and PGD. start out with quite long delays (10uS or so) after each of the 8 edges. then get out the soldering iron and put in the resistors and capacitors suggested in the embedinc.com article. another angle: just did a few calculations. if i am not mistaken, with 100pF of capacitance and a 3k3 resistor, to achieve going from '0' to 65% of Vcc will require 350uS. this is pretty dismal. assuming the pins have 10pF of capacitance inherently, this becomes 35uS. assuming we cut the resistor down to 330 ohm, this brings it down to 3.5uS. i'd try dropping the resistor down to 330 ohm (before making any code changes) and see if things still work. this will have PGD driving 10mA, 2/3 of its rated limit. this should do no physical harm. if it doesn't work, step up to 560 ohm, 1k, etc. report back the lowest value that seems ok. i'd be reluctant to go below 330 ohm. rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
100pF of capacitance and a 3k3 resistor, to achieve going from '0' to 65% of Vcc will require 350uS oops, scrub that - i think i may be out by a factor of 1000! 100pF, 3k3, gives a rise time to 65% of Vcc of 0.35uS in fact. the 32MX datasheets also seem to indicate an input capacitance of pins of around 10pF. rob [looking very embarrassed!] |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
The 100R+47pF stuff has to be at the target end of the ICSP cable, which means that people who produce the target boards have to include extra components none of which are specified by MCHP and which will cost them, so they won't do it. Another alternative is of course to put the PIC32MX on a bit of stripboard with these damping components and fit the board with an ICSP socket header, ie just like a PicKit2/3, and of course one could put the ICSP socket header and damping components on a little strip board and then run the cable back from that board to the PIC32MX. I'm not sure all of this really helps the MMBasic version of the programmer become noticeably quicker. The really key function is XferFastData, and when I had the Clock instructions in a separate function call, the execution time was over 94mS per XferFastData call, by inlining the code into XferFastData itself, the XferFastData execution time dropped to 47mS which is much better of course, but when programming 128K it still takes an awfully long time ! I can probably squeeze out a few more mS with tighter coding, maybe as much as 10mS if I really try hard. I suspect that this may be one area where MMBasic will just not be quick enough for practical purposes - if only one could call a machine code function from MMBasic a la ByPic style ! 73 Peter BTW, ByVac are shipping 170F ByPIC chips - see sys report below ====================================== | ByPic Version 2.30 (FP) | Saves 0 | | MX170 Serial# 201402052 | | | Documentation www.bypic.co.uk | | | | Copyright Jim Spence 2014 | ====================================== ok sys sys System memory --------FLASH-------- User Start 9d01c000 Available 9d03fffc free 147452 Bytes --------RAM-------- Stack current a0000b08 stack top a0000bd0 free 200 Bytes Var local a0000ca8 Lvar top a0001478 free 2000 Bytes For stack a0001480 for top a00014f8 free 120 Bytes Var global (shares prog space) used 0 Bytes Heap current a0002150 heap top a000e4a0 free 50000 Bytes Return Stack Length 50 (Bytes 200) Temporary String Length256 (Bytes 256) Number of Temporary Strings 6 Default String Length 255 Loop Max 10 UART Buffer Size 255 System Flags 0x7fffffed Slack in bytes 5984 ok The only Konstant is Change |
||||
| Page 20 of 28 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
