 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 9 of 28   |
|||||
| Author | Message | ||||
| robert.rozee Guru  Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
how about revisiting the idea of a very basic 'PE' that just: (1) configures an onboard UART as a serial port, then, (2) sits in a loop awaiting blocks of data to write into flash. how much PIC assembler would be required to accomplish this? if one could configure said UART to use pins 4 and 5, the process of switching over to serial communications could be done transparently through the ICSP header. the micromite/maximite carrying out the programming would just need to use a pair of pins for PGC and PGD that also map onto one of MMbasic's hardware serial ports. do any forum members have any ideas on how to go about writing such a "micro PE"? how hard would it be? could it be done in just a few hundred bytes of code? rob :-) |
||||
vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
It may be worth checking how a mikroBASIC generate the .hex file for a simple "Blink-a-LED" example (it is free for small programs) ... and maybe the linker script ... I said it before, if I use XC32 for the same example and burn the code with pic32prog and a Pickit2 programmer, it verifies ok, but it never works. The same configuration bits as in mikroBasic, no special linker configuration. If I use mikroBASIC, or mikroPascal/mikroC, and burn the firmware with the same software and programmer, it works flawlessly. It writes something small in the boot zone... I guess is doing something Microchip is doing with their software to make the program run inside PIC32... This is true only for MX1/MX2 families. For others, the pic32prog with Pickit2 programmer works without problems. I mean, the Pickit2 firmware is known, the pic32prog sources are available, and it should work, except that little secret trick Microchip not telling us. But Mikroelektronika knows it, and prepares their firmware right so that it works with the pic32prog and Pickit2 programmer. Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| JTR0701 Regular Member  Joined: 10/07/2013 Location: AustraliaPosts: 71 |
Wow! I'm sure I have heard rumors of a USB bootloader for the PIC32MX220 that fits entirely in the boot block... |
||||
| JTR0701 Regular Member Joined: 10/07/2013 Location: AustraliaPosts: 71 |
Quick! Pass me my tin foil hat.  |
||||
| vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
I have a better idea. Do the tests and observe the behavior. Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| JTR0701 Regular Member Joined: 10/07/2013 Location: AustraliaPosts: 71 |
And that will prove your rather absurd conclusion? Really? |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
It would be a new thing with big benefits as currently the bootloader spills miles past 3K and has gaps. Not many lines of Pinguino code overflow what's left. I bought a couple of other PIC32MX boards instead (but they're not supported by Pinguino, as no USB, not that I mind) to allow some other tests. John |
||||
| vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
That is about an USB HID Bootloader for 8bit microcontrollers. The one for PIC32 is only serial and hardly fits in 3Kb using the professional XC32 compiler. No chance using the free edition so I would say it is forbidden for hobby use. I tried and I also made some noise about the subject but, as long as there are users who blindly defend Microchip, there is no chance of a change. Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
But if the rumor is true, it has to be in assembler but I highly doubt it. The HID Bootloader of Diolan made for PIC18F2550 fits in 2Kb as opposed to Microchips's 4Kb. If we multiply by four, we get around 8Kb of code for a HID Bootloader in assembler for PIC32. The current HID Bootloader of Pinguino32 MX220 written in C is about 16Kb in size if I'm not mistaken. Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I think it is not so much a priority for Microchip as they are more geared for the professional market who incorporate their products in appliances and gadgets. No need for a bootloader, instead the pricepoint of the devices and the diversity has their priority. However i think that is not very forward looking as more and more 'makers' use the chips and they will be the next generation producers of products. Making the chips more maker friendly would be a big advantage. Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
I think it's short PIC32 code and as I mentioned I think OpenOCD has it already so it could just be reused. It may expect 4-wire JTAG, as OpenOCD is pretty keen on JTAG, so some tweaks may well be needed. John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
I have already done this before for 8 bit pics and would not be difficult to do in assembly. All of the routines currently on the uMite for this project can be translated to super fast assembly routines. However, the aim was for a hobbyist to programme a pic32 just using a MMite and not a PICkit3 or equivalent and without having to programme a serial dongle. My original aim was to use a MMite because of its SD card so that PCs can be eliminated. (other than to produce the .hex file). I think it is still possible to do this using a MMite but the PE is needed to get any sort of speed. The challenge is in downloading the PE. The PE loader is "easy" enough as it uses the already written pseudo codes in MMbasic. David M. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
MOBI: is the bottleneck in the slow speed of writing data over the ICSP port, or the speed hit taken from not using a PE? in both cases, using the ICSP functionality to first clear flash and then load a 'micro PE' into the target 32MX150 would seem to be a solution. the micro PE (if just a few hundred bytes long) could be held as old fashioned lines of DATA statements in the MMbasic code, prior to being inserted via the ICSP connection into the target's RAM. once the micro PE was in place and running, sending the firmware to be written into flash over a TTL-RS232 link would be trivial. the micro PE would only have to respond to a single command, being something like <starting address> <data........> <checksum>, with a response of '1' as command completed, and '0' as command failed. the micro PE would have no need to know how to talk via the ICSP connection; all it would need to be able to do is receive blocks of data down a serial port, verify a simple checksum, and then write the data into flash. rob :-) |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Clocking out one command using 2 wire ICSP takes around 140 or so clock pulses which means at least that many MMbasic interpreter instructions. Just to put data in a RAM location requires a number of commands multiplied by the number of clock pulses per command. I think that running the MCHP PE is the way to go if it can be done. I have figured out how to load the PE preloader but not the actual PE itself or how to send the HEX data to the PE for programming the flash. There is quite a bit to absorb and if anyone wants to do the research, please feel free - this project is using up a lot of my time that I should be spending on other matters (like my up coming Europe holiday etc.) The PE is only a few hundred bytes long anyway. Yes, it could be DATA statements (I had considered that) or read from a .hex file on the SD card. The PE binary file is in MPLAB X and also I believe, in a C header file. That was roughly how I did my 8 bit pic/AVR programmer. David M. |
||||
| JTR0701 Regular Member Joined: 10/07/2013 Location: AustraliaPosts: 71 |
By my numbers the MX1xx and MX2xx the PE code (largely written in MIPS16e) is 1688 bytes or 422 words, while the PE code for the rest of the MX family is 4168 bytes or 1042 words. Perhaps you are confusing the programming executive with the debug executive which is substantially smaller. |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Yes, perhaps. The file I am looking at is 32PE.hex in the Microchip MPLAB X folder @ 11.2KB - not exactly over sized. I haven't analysed the data to see if it is the PE I want or not. MCHP forum gave a brief excerpt of the PE on a previous search, I'll go back and compare the data with their example. Meanwhile, I have been reading up on the operation of the JTAG system. Quite simple when it all comes down to it. Compelling reading for anyone who wants to know how the various programming pseudo codes etc. work. ===================== Just had a check of the Mchip forum and the example they give is identical to the PE32.HEX file in MPLAB X. Close enough for my liking and I don't think the loading would be too difficult. (google search - pic32 programming executive). David M. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
is communications with microchip's PE substantially simpler/quicker? rob :-) |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
As it runs in assembly language in the target ram, all that should be necessary (I haven't checked yet) is to transfer the flash data one row at a time and the PE does the rest in super quick time. The current slowness is due to the MMbasic interpreter and the large number of MMbasic generated clock pulses. If we swap to 4 wire programming, the programming time would be roughly a quarter. I think when I finish with the Micromite development and go to the MM, I'll start another thread as this one also looks at using just the usb serial cable and associated control lines. David M. |
||||
| JTR0701 Regular Member Joined: 10/07/2013 Location: AustraliaPosts: 71 |
Remember, it is ripe_11_xxx.hex you want and not ripe_06_xxx.hex. Generally when you see a "refactored" or "dataized" (just made that word up)  PE file it is most likely to be ripe_06_xxx.hex. Not the one you want for the MX1 and MX2. However Serge of pic32prog fame has done a lot of the PE leg work already.
link Should be a cinch to convert to BASIC I expect. |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
I have had a read of your link to Serge's data. The only ripe_11_.... file I can find in MPLABX is RIPE_11_000301.HEX I assume this is the one that is needed? Where did you find this information? I thought I read in one of the pic32 programming docs that the PE was a PE32.HEX (or similar) but I have read so many articles on programming the PIC32 lately that I am a little (more than a little) over indulged. I am going to try to get data into the target flash by not using the PE first and the hell with the verify function just yet. I'll soon know if the right data gets in. I like the term "dataized" I think I'm suffering from "data eyes"  David M. |
||||
| Page 9 of 28 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
