 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 8 of 28   |
|||||
| Author | Message | ||||
| robert.rozee Guru  Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
if you wanted to expand on the pins available on the serial port, one option would be to use an arduino pro mini as an I/O expander: http://www.ebay.com/itm/251525943717 the one in the above auction runs the processor at 3v3, with an 8MHz clock (the 328p won't run at the more common 16MHz with a supply below 5v). the pro mini would provide you with the following advantages: 1. more than enough I/O pins, with the ability to tristate outputs when required, 2. can handle the quick toggling of pins to achieve a good throughput, 3. programmed in C, with no extra hardware needed to upload code, 4. ability to implement a 'software' USB interface if desired. one might end up with such a pro mini being a "mini picket3" if some of the programming algorithm is offloaded to it (ie, have the pro mini generate the clock pulses itself). of course, this path would not be required for the micromite-reprogramming-micromite scenario. if running the programming software on a micromite (or maximite) there are far better solutions for getting the bits into the target 32MX150. rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
microchip seems to start from the assumption that one should be doing all communications in a programming session through just the ICSP interface. but why do we need to be limited to this? how about having both an ICSP connection to the target, as well as a second connection to one of the target's hardware serial ports? one can then load a program into RAM (via ICSP) who's sole purpose is to configure the serial port and accept through that port blocks of data to be written into flash. the only requirement is the need to be able to get a chunk of code that is resident in RAM executing and in a position where it can enable one of the hardware serial ports and make use of it. no need for fancy interrupts and buffers here, just poll the serial port in the simplest possible way, with handshaking via acknowledgement messages after each block is written into flash. rob :-) |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
I did kind of suspect that the so called PE was just a PE loader. I got the feeling also that somewhere there is a .hex file of the PE that can be downloaded, I haven't looked fully yet. Also, the docs imply that all programming can be achieved without the need for the PE. Do others share this view? If so, perhaps in the meantime, we should get things working without the PE. In my early development of the current status of the uMite firmware, I did things a bit "long hand" particularly with the 4 phase clock generator. The purpose was to make the operations more understandable. Once things were 'go', I intended to speed up the code - even use 4 wire method. The use of binary strings makes things easy to read and implement, but slow. ================ A note in the docs - Note: The Programming Executive (PE) is included with your installation of MPLAB® IDE. To download the appropriate PE file for your device, please visit the related product page on the Microchip web site. Has anyone checked this? David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Yes, the actual PE is on the chip page as a fairly small file. They have names like RIPE_* I don't know for certain but think the PE is not essential. John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
I planned to avoid anything that requires programming - may as well use a umite in a way, otherwise. Though... maybe. There's probably a cheaper device still that already has USB connector etc. Not sure what... Maybe one of those USB logic analysers EZ-USB FX2LP CY7C68013 things. Very cheap. John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Question on the 60001145N datasheet. 5.3.1 refers to 4 clocks. Then says ... falling edge ... falling edge... But Figure 5.4 shows the rising edge for the 4th clock. Which is right? If the Figure is right, as I suspect, then PGD should be read after setting Clk hi. Right? I see Keith's code samples while Clk is still 0. Why does it work (if it does)? Is it that the chip sees the Clk fall to 0 and begins putting out TDO any time it gets around to it? John |
||||
| JTR0701 Regular Member  Joined: 10/07/2013 Location: AustraliaPosts: 71 |
No, not right. "On the falling edge" really means before the next rising edge. Therefore, where the arrows are really means the data must already be valid and the sampling must already be completed. Remember, the direction (and source) for TDO data has changed (compared to TMS and TDI) after the 3rd rising edge. When seen from the DUT side, PGED turns around from being an input (TMS and TDI) to being an output (TDO) on the rising 3rd phase clock and its data output will be valid on the falling of the 3rd phase clock. This is when it needs to be sampled by the master and this is what Keith's code (plus my code, plus microchip's code) does (and clearly it works.) The DUT will then take the 4th rising edge as it cue to release PGED. At this point it is too late for the master to sample the TDO data as you would now be in a critical race condition. Edit. When understood like this, there is no inconsistency between the text in 5.3.1 and what is shown in figure 5-4. Not that I can see anyway. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Thanks. So 5.3.1 is meant to mean "... while TDO is driven BY THE PIC32 on (*) the falling edge of the THIRD CLOCK on PGECx"? I suppose I'm wondering how soon after that falling edge I can read the value of TDO. I'm not using a slow language like Basic. And the PIC32 turns its PGEDx back into an input ... well, maybe on the next rising edge or some such. (*) or I suppose some small delay after Er... what Microchip code? Do tell! John |
||||
| JTR0701 Regular Member Joined: 10/07/2013 Location: AustraliaPosts: 71 |
Re 5.3.1 PGED changes direction on the rise of the 3rd clock. The data out (TDO) is valid 10ns after the 3rd rising edge. Given that we read it after the 3rd falling edge, the 10ns is well past. Now where did I get this value of 10ns from you may ask. Scroll down to page 59 (DS60001145N) and look at the P15 characteristic. What microchip code? Well I tend to poke around a bit in all their code but in this case I am referring to the PICKIT 2 firmware that is now public domain. From pickit2.asm: ;/********************************************************** ******************** ; * Function: JTAG2W4PH primitive ; * ; * Overview: assembly primitive for PIC32 2-Wire 4-Phase JTAG ; * ; * PreCondition: tris_ICSPCLK = 0 (output) ; * ICSPCLK_out = 0 (low) ; * ; * Input: ASM_TEMP1_RAM - TDI (output) value in bit 0 ; * ASM_TEMP2_RAM - TMS (output) value in bit 0 ; * ; * Output: ASM_TEMP3_RAM - TDO (input) value in bit 0 ; * ; * Side Effects: tris_ICSPDAT set to output, then to input ; * ; * Note: Use with an assembly CALL instruction. ; * Min PGCx high or low time = 83ns ; * 25 instruction cycles (including CALL & RETURN) = 2.1us ; ************************************************************ *****************/ JTAG2W4PH: bsf LATA, 3, 0 ;// CLK high phase 1 bcf LATA, 2, 0 ;// TDI = 0? btfsc ASM_TEMP1_RAM, 0, 0 ;// Test for TDI value bsf LATA, 2, 0 ;// TDI = 1 bcf TRISA, 2, 0 ;// Output TDI (PGD = output) nop bcf LATA, 3, 0 ;// CLK low Phase 1 btfss ASM_TEMP2_RAM, 0, 0 ;// Test for TMS value low bcf LATA, 2, 0 ;// TMS = 0 bsf LATA, 3, 0 ;// CLK high phase 2 btfsc ASM_TEMP2_RAM, 0, 0 ;// Test for TMS value high bsf LATA, 2, 0 ;// TMS = 1 bcf ASM_TEMP3_RAM, 7, 0 ;// TDO = 0? bcf LATA, 3, 0 ;// CLK low Phase 2 bsf LATA, 3, 0 ;// CLK high phase 3 bsf TRISA, 2, 0 ;// Input TDO (PGD = input) bcf LATA, 3, 0 ;// CLK low Phase 3 bsf LATA, 3, 0 ;// CLK high phase 4 btfsc PORTA, 2, 0 ;// Test for TDO value bsf ASM_TEMP3_RAM, 7, 0 ;// TDO = 1 bcf LATA, 3, 0 ;// CLK low Phase 4 return GLOBAL JTAG2W4PH |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Not sure I totally agree. In most digital circuits using shift registers, data transfers are edge triggered to determine the precise moment at which data is available and where. That is not to say that the data may not be available earlier but that would mean going against timing convention. I am still using the clock timing I first came up with and it works just fine. @JohnS - I used to use ICProg to programme all my pics using the Silocon Chip programmer which used the control lines of a comm port to do the signalling. Fine until Bill Gates and laptop makers took away the comm ports. I tried using a usb to serial adapter with VB6 but the 'break' line kept resetting. I ended up writing picF88 interface to interpret the programming commands and using standard serial data. David M. |
||||
| Keith W. Senior Member  Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Hi all, I am a hardware person and in fact the chips are constructed this way. When I looked at the timing diagram with the arrows I treated it as constructing a hardware solution. Imagining that the clock is generated by consistent hardware timing and TDI and TMS is latched into the chip register(s) on the falling arrowed edges and TDO latched back into the Programmer on the arrowed rising edge. As a hardware person arrows are telling me latch on this edge. But from the diagram TDO was available perhaps before the third falling clock edge. In my hardware solution, as I have latched the TMS data on the falling second clock edge, immediately after latching represents the earliest (safest) time that I should make PGED an input. As I am actually using software I know that due to processing time taken I can sample TDO after I drop the third clock which in practice will be more than sufficient delay. I think it will still work OK if I had sampled TDO just after the rising edge of the fourth clock (in software I cannot sample and change the clock at the same time) but before the fourth clock falls. 
Keith W. |
||||
| JTR0701 Regular Member Joined: 10/07/2013 Location: AustraliaPosts: 71 |
Well first of all, we are not talking about shift registers here and there is some difference. We are talking about when the firmware samples PGED and not a hardware latch. It is clear is that TD0 is driven from the DUT on the falling edge of phase-3 and can be sampled anytime after P15 elapses. It could well be that it can be sampled anytime up to the fall of the phase-4 clock. This is where the programming specs appear to become fuzzy. The diagram clearly shows the change on the rising edge of the phase-4 clock. But if it is that TDO remains valid until the falling edge of the phase-4 clock (and indeed it appears that it does given that your code and the above microchip code work) then it is just splitting hairs as to when we sample TDO. Either method would work and the firmware has that flexibility because it is controlling the clock and not the DUT. However... You are missing the point both Keith and myself made about your timing. Your code is not turning around the PGED I/O before the phase-3 falling edge. Therefore you are driving the PGED in opposition to the DUT until you do. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Thanks all. I'll go hunt the rest of the code (edit: code ), even if it is ASM. Mchp could really help their customers by releasing C rather than somewhat terse data sheets with frankly poor and imprecise English. I've sent Mchp various errata etc for their PIC32 data sheets (and they've used them) but it's a thankless task. Why they put Data Out instead of TDO I don't know. Just asks for people to struggle. Bit like showing 6 instead of at least 2 sets of 4 phases. Even odder to fail to show actual levels with bit values. And the lack of a timing diagram showing P15 is completely inexcusable IMO. How the miserable wording "Data Out Valid from PGECx (up arrow)" is meant to be understood is beyond me since it could mean any of several things (becomes Valid, remains Valid, etc) and simply needs to be on a diagram. Oh well it's only datasheet rev N. Various parts of the data sheet read as if one is expected to be creating a PIC32 clone rather than a device to program one. Well how daft. The failure to be clear about when a programmer should set its PGEDx as an output and when it shouldn't is symptomatic. I see they sometimes want MSB first and sometimes LSB but also do odd things like wanting one but referring to it in the other notation (TMS header cf SetMode). At least there are some diagrams to show what they mean, sometimes. So, JTR thanks for the ASM (horrid though it is). It reads TDO very late, much later than I understood was to be done. Oh well. MOBI - I didn't know Silicon Chip had such a thing (never heard of the magazine till the Maximite referred to it). Meanwhile, I've had another idea while I wait for chips to turn up. John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Hello all, Back again - I haven't had much time to dedicate to the pic32 programmer of late but have got it to check status erase device and display device id code. I have all the routines to download block of data, do a block programme and verify memory all written but not debugged. I thought after performing an erase, I should be able to do a verify simple enough .... but .... the instructions are not the clearest and as yet I'm not getting a valid read happening. I have set it up as menu driven using some VT100 terminal screen clear and cursor position commands. Makes it much easier to handle. Has anyone else progressed to this stage or further? David M. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
i think everyone is waiting with baited breath, their hopes pinned on you! the british are awaiting the arrival of further hardware supplies, while others are struggling on through the microchip data sheets. an idea - and a general question for all - relating to the need for getting some extra data output pins on a PC: how practical would it be to connect (a) a USB to serial bridge (such as a CP2102) to the USB port of a PC, then attach (b) a low-end PIC that can be programmed with just 5v to the bridge, which would then itself connect to (c) the 32MX150. the connections between (a) and (b) would be arranged such that the low-end PIC could both (1) be programmed via the USB to serial bridge, THEN, without need for rewiring, (2) be used as a further bridge to the 32MX150? the low-end PIC would then serve a bit like a PICKIT2, handling the packaging up and unpacking of the bits going to the target. it would seem that the code in this low-end PIC may be quite simplistic. just another idea that popped up. rob :-) |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Hmmm. @rob I would probably advance a bit faster if the MicroChip documentation wasn't so contradictory as well as being home long enough to try a few experiments. Also, a better understanding of JTAG wouldn't go astray. As I understand it, a pic32 can be programmed using a number of techniques. Just getting one to work would be fantastic. The documentation assumes that the reader is au fait with its generalisations. As far as programming a low end PIC interface, I did that a few years ago for both 8 bit PICs and AVR chips using a PIC16F88 and a usb-serial cable. It meant having to write a VB6 app to do the (source code assembly and) programming algorithms. It still works well. I did it because there were no comm ports on my laptop (the only pc I have)and using a usb-serial cable on its own was mortally slow. All data transfer was done using async serial and a sort of jtag command system. My aim with this project (I know it is not what you initially proposed) was to use a MM to programme a uM. I have a problem with xferdata() and xferfastdata() in that can I use either to read data from the flash or must it be only xferfastdata? David M. |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Hi Mobi, My impression regarding data transfers. In the beginning to put anything into the chip XferData enables you to send and receive from SPECIFIC REGISTERS that have been selected by preceding commands. Then XferInstruction enables commands to be sent that are each executed immediately upon reception. However some data for memory can be embedded into for instance the lower 2 bytes of the 32 bit instruction. This is how the” PE Loader” is loaded into memory. Data is placed into memory by the instruction as it is executed. Once the” PE Loader” is in memory and executing do the following steps to load the full PE. Now at Step 7 from page 24 Command(Etap_FastData) XferFastData(StartAddress) Start of PE block from PE file XferFastData(WordCount) Number of 32 bit words of PE Then send the PE by successive XferFastData( PE(1) to PE(WordCount)) Step 8 XferFastData(00000000) Last -1 transfer XferFastData(DEAD0000) Last .. Which causes the PE to start running. From the above I think that the PE Loader is required here to handle data transferred by XferFastData otherwise why is the PE Loader required to load the PE? This is the first time that XferFastData is used here. Further: - Looking at Table 14-1 it seems that to read memory a small “Reader” is placed and executed for each transfer of data into the FastData Register for reading i.e. location FF200000 via steps 2 to 4. You might as well load the true PE once as do this for each location to be accessed. In answer to your previous post: - I owe you an answer but hope not to dissuade you or others from continuing and am sorry that so few are attempting the quest. I have chickened out. I began because TBS members were having trouble starting ICSP communication, and a simple Pic32MX Programmer would be useful. I believe that full chip Programming is “technically” possible with a Maximite/Micromite in some form. However after helping to demonstrate that ICSP can work with MMBasic I lost the incentive to continue. For this project MMBasic keeps my old fingers too far from the binary bits. My more familiar hardware is calling from the cupboard to be my answer. In Assembler. But this would be unique to me and I will not pursue it. I will follow others progress here with interest and probably still butt in and will be very happy to assist with any knowledge I have gained. Keith W. |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
@Keith, Thanks for the explanation, it confirms much of what I suspected. I was rather hoping that others might develop different and more efficient ways to perform the programming tasks. I tried other ways to start with including data in numeric form but had problems with unsigned 32 bit words and so settled on using strings as they are easier to read. I might end up giving numeric bit arrays a go when I can get data into the flash and read it back with the current method. I would like to take a step back and get a better understanding of the TAP system in order to understand what Mchip are trying to say. It would be nice if they stuck to one method of description e.g timing charts and instruction steps instead of reverting to narrative implications such as "read fast data register". (rhetorical) do they mean xferdata or xferfastdata? and what do the "address" and "data"registers do. I suspect in previous posts on this subject that there was a bit of confusion between PGCk of the two wire 4 phase and TCK of the 4 wire method? It also didn't help that I had a TMS variable conflict that wasted a lot of time. It would be nice to have the time to dedicate to this project but we are away from home and my workshop a lot and there is only so much one can squeeze into a ute back camper and still be comfortable. Your project? Assembly language programming? - my favourite - have been doing it for around 45+ years in one form or another. Challenges the brain to think abstract. David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
I wrote some C but needed to order chips as the USB-to-serial devices provide too few outputs. When they turn up and I have time I'll have a go at seeing if it works. I tried using a PIC32MX220 Pinguino board I have but it is crippled by a flabby bootloader and fat USB stack so ran out of memory. Oddly, I did manage to erase MMBasic 4.5D's bootloader (on a MX150 board) without meaning to and don't know how. (Reflashed using PICkit3 but odd it vanished.) John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
You must have "lucked" the right command. Mind you, erasing the pic is relatively easy. I have just finished trialling a rehashed routine to verify the data written to the flash and it takes about 2 seconds per location. The verify is far shorter than flash write so I have about come to the conclusion that this whole project is a bit of a dead ender. It might be easier (as I think it was Keith said) to load the program executive and be done with it. It might even be more advantageous to try the 4 wire method for extra speed except that it doesn't fit the normal ICSP header. Beginning to think my initial gut feeling of S L O W was correct. David M. |
||||
| Page 8 of 28 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
