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 : pic32prog
Page 1 of 4 | |||||
Author | Message | ||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
pic32prog has now been updated to use a us$3 Arduino NANO to upload firmware to a PIC32MX processor. it can therefore be used to either update micromite firmware, or to create new micromites and maximites. the micromite mk2 (MX170) firmware takes about 2 minutes to upload. pic32prog.exe for windows is located here: https://github.com/sergev/pic32prog/raw/master/pic32prog.exe (direct link to .exe) and the instructions for building the hardware (consisting of Arduino NANO, 5 resistors, and a 3v3 zener diode) along with the arduino sketch to implement the "ascii ICSP" protocol are located here: https://github.com/sergev/pic32prog/tree/master/bitbang (file list) the command line for using pic32prog is: pic32prog -d ascii:<port> <firmware.hex> many thanks to all those TBS members who helped out with beta testing the code and proving the hardware design. cheers, rob :-) C>pic32prog_ -d ascii:com5 MM_v4_78.hex
Programmer for Microchip PIC32 microcontrollers, Version 2.0.134 Copyright: (C) 2011-2015 Serge Vakulenko (ascii ICSP coded by Robert Rozee) Adapter: OK1 OK2 - ascii ICSP v1C Processor: MX170F256B Flash memory: 256 kbytes Boot memory: 3 kbytes Data: 256872 bytes Erase: 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: 2204 bytes per second total TDI/TMS pairs sent = 3144806 pairs total TDO bits received = 499544 bits maximum continuous write = 934 chars O/S serial writes = 95674 O/S serial reads (data) = 15619 O/S serial reads (sync) = 1567 XferFastData count = 57792 10mS delay count = 11 elapsed programming time = 1m 58s C> |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
attached is a new test version of pic32prog which is capable of itself uploading 'ascii ICSP' firmware to an attached "Arduino NANO", "Arduino Pro Mini", or "Arduino Duemilanove" (i have tested upload to all three). it should, in theory work with just about any 328p-based arduino. pic32prog.exe is the only file needed. embedded within this version of pic32prog is the compiled 'ascii ICSP v1C' firmware for the arduino, along with an arduino/STK500 uploader routine. there is no need for the Arduino IDE or a copy of avrdude. the procedure for creating a us$3 ICSP system is now as follows: 1. build up the programmer (circuit diagram in the attached zip file) using an arduino, 5 resistors, a 3v3 zener diode, and cable+plug to run to the 6-pin ICSP header on your PIC32MX setup; 2. connect the arduino to your PC and run pic32prog as follows: pic32prog -d ascii:com5 -b3 where 'com5' is the comm port the arduino appears as under windows, and '-b3' selects the arduino bootloader speed. if '-b3' does not work try '-b2', '-b4', or '-b1'; 3. attach to your micromite or maximite and upload MMbasic firmware with the command line: pic32prog -d ascii:com5 MMbasic.hex where 'MMbasic.hex is the micromite or maximite firmware file. note that step 2. only needs to be performed once, after which the reset line on the arduino can be jumpered to ground for quicker serial port opening. cheers, rob :-) 2015-06-27_151154_pic32prog_v2.0.2.0.test-28-JUN-2015.zip |
||||
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Robert How does this relate to the USBASP h/w, ie can the USBASP be used ? USBASP-eBay http://www.fischl.de/usbasp/ Thank you Peter The only Konstant is Change |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
i did look at the USBASP hardware, but was unable to determine if it uses a bootloader (am pretty sure it does not). without an onboard bootloader one arrives back at the chicken-and-egg problem of how to get the device programmed in the first place without needing to use another programmer. i believe JohnS struck this problem. on the plus side, the USBASP designs do their USB on the processor chip (in software), and the ATmega8 processor they use does have sufficient RAM (1k) for reasonable throughput - i'm currently using a 1k serial Rx buffer as a means to achieve cutting the programming time of an MX170 micromite from 4 minutes down to 2 minutes. a 512 byte buffer would just suffice. but about the only thing out there that ships as standard with a bootloader (and is very cheap) is the arduino. i discovered the STK500v1 protocol used for uploading firmware is relative simple (the arduinos use a cut-down version of the protocol), making it quite easy to add in an 'upload' facility to pic32prog. btw, i shall be publishing my source code soon, right now am still sorting out a few loose ends mulling over how to make it look a little prettier! of course, one could always write an arduino 'sketch' that implements a faster protocol than 'ascii ICSP', but 2 minutes seems pretty acceptable for the average hobbyist, and i'd still recommend pic32prog + pickit2 as the best solution if speed is important. cheers, rob :-) |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5911 |
I have a pickit3 so there is no need, but I just ordered a NANO to play with. It will take a couple of weeks to arrive and then I can see how an "arduino novice" goes. Jim VK7JH MMedit MMBasic Help |
||||
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Thanks for explanation Robert Peter The only Konstant is Change |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
the NANOs are quite neat little devices, very affordable at just a few dollars for clones delivered from ebay china. and the more recent versions of the Arduino IDE (1.6.5 is the latest) are quite stable and simple to use, effectively shielding the user from all the 'bookkeeping' usually associated with writing a C application from scratch. basically the IDE presents you with a very simple shell into which you insert 'setup' code iton one place, and 'loop' code into another. you still need to get your head around the cryptic nature of the C language, but there are a great many examples provided which helps a great deal. my only real complaint is the need to install the complete IDE (over 100mb) just to upload the code for a project - a considerably bigger step than getting teraterm up and running to talk to a micromite. have a look at the April 2015 silicon chip article about building a weather station based on the NANO. to get around this, i've created a small routine to talk to the Arduino bootloader (which uses a subset of the STK500 protocol) directly and upload a pre-compiled .HEX file. this is what is used in the copy of pic32prog a couple of messages up, and i am thinking around the best way to make it into a standalone program. it will likely be used thus: upload328p <comport> <filename.HEX> right now, what i have is a delphi application that decodes the .HEX file (and converts in into an array of bytes), and a C routine to do the uploading. cheers, rob :-) |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5911 |
I finally found time to test this method. I tested on a slow Windows 10 laptop and it was the first time it had seen a NANO. c:\apps\pic32>pic32prog -d ascii:com5 mx150_28pin.hex
Programmer for Microchip PIC32 microcontrollers, Version 2.0.test-28-JUN-2015 Copyright: (C) 2011-2015 Serge Vakulenko (ascii ICSP coded by Robert Rozee) Adapter: .....OK1 OK2 - ascii ICSP v1C Processor: MX150F128B Flash memory: 128 kbytes Boot memory: 3 kbytes Data: 134144 bytes Erase: 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: 2640 bytes per second total TDI/TMS pairs sent = 1735287 pairs total TDO bits received = 318904 bits maximum continuous write = 934 chars O/S serial writes = 52646 O/S serial reads (data) = 9974 O/S serial reads (sync) = 834 XferFastData count = 30671 10mS delay count = 11 elapsed programming time = 0m 52s c:\apps\pic32> Quicker than waiting for the Microchip software to boot up. I used an MX150 chip for the test because it was close to hand and they are probably feeling a bit left out with all the interest in the new toys. Thanks Rob. Jim VK7JH MMedit MMBasic Help |
||||
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Jim, Were you successful? If so, which firmware version did you load into the MX150; and approximately how long did it take to program? Thanks WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5911 |
I loaded the latest I had for the 150 which is V4.5D I did load an earlier version first to make sure that I could see the changes. elapsed programming time = 0m 52s Not bad. The system was able to provide enough power to the MX150 so there was no need for any other external power supply. I am not sure if powering the chip externally would cause any problems. You might end up back feeding the NANO, which would be a NONO. Just to make you feel better, Snow on Monday, Frost on Tuesday, Hail today.... Jim VK7JH MMedit MMBasic Help |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
the way power is supplied by the NANO to the target pic32 means that backfeeding 3v3 should not worry the NANO - when Vcc is off, the 3 pins feeding in to the Vcc line are open-circuited. Vcc on/off is controlled by pic32prog, and turned on just before programming starts and turned off when it finishes. however, the 3v3 zener diode from Vcc to ground may become a tad unhappy depending upon the exact voltage being backfed/applied directly across it! the zener's actual clamping voltage can in practice be as low as 3v0 or as high as 3v6. for powering the pic32 externally, i'd advise disconnecting the Vcc line from the ICSP connector, or use a 3v9 zener and add a blocking diode in series with the Vcc line. the latest version of pic32prog, with all my changes now merged, is available on serge's GitHub site. the .exe is at the same location as the link in the first posting to this thread: https://github.com/sergev/pic32prog/raw/master/pic32prog.exe cheers, rob :-) |
||||
trevoz Newbie Joined: 03/05/2014 Location: AustraliaPosts: 8 |
Another success story: Windows 10 VM in OS X Mavericks under Parallels 11. Chinese Nano clone with CH340 USB chip - amazingly the correct USB driver was automatically installed by Windows 10... and worked :) >pic32prog -d ascii:com3 -b3 Programmer for Microchip PIC32 microcontrollers, Version 2.0.157 Copyright: (C) 2011-2015 Serge Vakulenko (ascii ICSP coded by Robert Rozee) 57600 baud ... synchronized Signature = 1e950f Device = ATmega328P ############################################ Firmware uploaded to 'ascii ICSP' adapter OK >pic32prog -d ascii:com3 MM_V4.7B23.hex
Programmer for Microchip PIC32 microcontrollers, Version 2.0.157 Copyright: (C) 2011-2015 Serge Vakulenko (ascii ICSP coded by Robert Rozee) Adapter: . OK1 OK2 - ascii ICSP v1C Processor: MX170F256B Flash memory: 256 kbytes Boot memory: 3 kbytes Data: 258956 bytes Erase: (80mS) 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: 1607 bytes per second total TDI/TMS pairs sent = 3108619 pairs total TDO bits received = 445584 bits maximum continuous write = 934 chars O/S serial writes = 94803 O/S serial reads (data) = 13932 O/S serial reads (sync) = 1583 XferFastData count = 58384 10mS delays (E/X/R) = 8/0/0 Tip: Required jumpering of RST and +5V on the Nano or "No response from 'ascii ICSP' adapter". |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
it does seem that under certain conditions, the operating system is twiddling the DTR line on the serial port sufficiently to prevent the NANO from responding in a timely fashion to pic32prog's initial 'hello' messages. i may extend the current 5 second timeout (250mS x 20) to 10 seconds in order to get around this. jumpering RESET to +5v (once the 'ascii ICSP' firmware has been uploaded) completely stops this issue by disabling the NANO being externally reset. just remember that with RESET jumpered to +5v, pressing the reset button on the NANO will short out the (in theory 100mA current limited) USB 5v supply! note: earlier on in this thread i incorrectly mentioned jumpering RESET to GND. when jumpered to ground, the NANO's processor is completely shut down, leaving it non-responsive and usable as a USB to serial bridge. the latest version of pic32prog can always be downloaded from here: https://github.com/sergev/pic32prog/raw/master/pic32prog.exe (direct link to windows .exe) pre-compiled versions for ubuntu linux and mac OS X are also available at: https://github.com/sergev/pic32prog cheers, rob :-) |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
now that is embarrassing, it doesn't work correctly under linux with a CH340G based Arduino NANO - the most common variety! it looks like there may also be issues with OS X too. the linux problem is that the default linux drivers that talk to the CH340G only support a very limited set of baud rates. at the same time, the Arduino NANO also has some severe limitation on baud rates that it can handle - above 115,200 the baud rate really does need to be a multiple of the 16MHz clock. i had chosen 500,000 as Windows was happy with this and it allowed quite a bit of leeway for speed gains elsewhere. but neither linux nor OS X like this baud rate when a CH340G is involved. the solution: firstly, i've dropped the serial speed back to 115,200 baud. unfortunately, this means that without changes elsewhere the serial link (between CH340G and ATmega328P) becomes a bottleneck, pushing out programming times to 4 minutes or so. to counter this, i've extended the 'ascii ICSP' protocol to allow encoding 4-bits of flash data into a single ascii character (previously each character could only carry ONE bit). this has cut the volume of traffic by nearly 70%, and pretty much restored the programming time back to about 2 minutes. here is a beta of the 'fixed' version: 2015-08-29_154240_pic32prog.zip usage is just as before: pic32prog -d ascii:com5 -b3 to upload the firmware (now version 1E) to the Arduino NANO, and: pic32prog -d ascii:com5 firmware.hex to upload your mmbasic firmware to the micromite or maximite. again, any beta testing folks can do would be much appreciated. the attached Win32 executable should also work on linux under wine - which i have tested. unfortunately i don't have the ability to produce linux and OS X compiles myself, i'm dependant on serge for these, but want to ensure the code is working ok before submitting it for inclusion in the master branch on github. cheers, rob :-) |
||||
trevoz Newbie Joined: 03/05/2014 Location: AustraliaPosts: 8 |
A pic of my Nano PIC32 programmer and patented veroboard addition :) The 5 programming pins are available on the top headers, while the bottom header plugs into the breadboard. Turns out the Nano PIC32 programmer is more than twice as fast as a PICkit2 using pic32prog! |
||||
trevoz Newbie Joined: 03/05/2014 Location: AustraliaPosts: 8 |
I have successfully compiled Robert's new version of pic32prog for OS X. I have tested it on OS X Mavericks and it works perfectly, albeit more slowly than under Windows (6 minutes vs 3 minutes to program MM BASIC). A ZIP file of the OS X 64 bit binary is attached 2015-09-10_113431_pic32prog.zip |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
@Rob, I have looked at the schematic for the nano and it looks pretty simple. Also the code that runs on the nano is well documented. I would like to investigate the possibility to extend the capabilities of my current USB-Serial 'block' to be able to act as a programmer instead of the nano. Reading the source it is stated that pins D2, D3 and D4 are used as Open Collector outputs. In the datasheet (page 4 point 1.1.6) of the 328 however it looks like those pins are not open collector capable but are of the push-pull kind. Is this an error in the documentation? Or am i overlooking something and the pins can be set into a open collector mode. I suspect that the pins are used in a normal output mode but only when the output is a logic '0'. When a logic '1' is needed then the pin goes to input mode and is high impedance. To simulate a Open Collector output. Would that be the case? To make the hardware more safe i could add a schottky diode. A mosfet to enable/disable power to the target would also be possible to add to the circuit if i can find one that is small enough. :) The user can determine if it is 5v or 3.3v with a jumper. EDIT: I changed my schematics with what would be needed to be able to use it as a programmer. What do you think? Microblocks. Build with logic. |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
TZadvantage: you are indeed correct, the 'open collector' effect is achieved by switching the pins between output and input mode. in every sense this is quite real, as the high-side transistor is always off, while the low-side one is toggled. the crude method of delivering power to the target (3x 100r resistors and a 3v3 zener) was used in the interests of simplicity. a mosfet is a tidier solution, but i didn't use one because of cost and complexity. i had also considered a 3-terminal regulator, but a zener was cheaper and the 50mA standing current draw was inconsequential. i spread the load across 3 output pins with balancing resistors to keep below 20mA/pin. do be aware that the (master) source repository at: https://github.com/sergev/pic32prog is lagging behind my one: https://github.com/robert-rozee/pic32prog the main difference being that serge's version is still running the serial connection at 500k baud, while mine has it throttled back to 115k2 along with extensions to handle 4-bit/symbol encoding. i am just waiting for serge to update his (master) branch. since you are using a single device for both USB bridge and programmer, the serial speed difference probably doesn't matter, but the 4-bit extensions will. however, they are backwards compatible. you may need to add a configuration jumper to your design to select the 'ascii ICSP' mode. this jumper could be inline with the pin 7 output - you could then sense the presence of the current 10k pullup to Vdd as indicating the need to enter 'ascii ICSP' mode instead of 'serial bridge' mode. i do like your idea, and fully support it cheers, rob :-) |
||||
Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
Actually I think it will matter. In my initial tests with the 16f1455 I was starting to get communications errors on speeds above 115200 Baud. It may be possible to get higher by adding a xtal but if your code is set to 115200 and we know that the 16F1455 is reaching the limit above that rate, I would say they are a good match. Cheers Chris http://caroper.blogspot.com/ |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Did you ever do programming of other ranges of PICs? The newer PIC16F among many for instance allow programming at VCC voltages. Are the hardware ruiguirements the same for these as the pic32mx series. If it is then a whole other range of pic could be programmed using the same hardware. Microblocks. Build with logic. |
||||
Page 1 of 4 |
Print this page |