TheBackShed.com

Forum Index : Microcontroller and PC projects : pic32prog

Page 4 of 4

Author

Message

MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209

Posted: 03:16pm 24 Sep 2015

Copy link to clipboard

Print this post

robert.rozee said
for a detection mechanism you could consider: a sequence of perhaps 10 '>' characters, after which the 1455 responds back to the PC with a '<'. if a '?' is then received from the PC switch to programming mode and send back the protocol ID string. you could combine this with the rule: after startup, if a character other than '>' or '?' is seen from the PC, lock out entry to programming mode. this would mean that programming or serial mode would be seamlessly selected at startup with almost no risk of accidentally triggering programming mode. just plug the 1455 into the USB port and start up pic32prog.
[/quote]
Yes,this is the way i do it now. Plugin the 1455 into the USB, Mode = UNKNOWN, then start a timeout and wait for characters to arrive. If it is '>>' then i enter Mode = PROGRAMMER state INACTIVE. This will then route any character only to the programmer software. If a '?' is received then the response is send back and the programmer state is set to ACTIVE. At this point the pins are configured. Until this moment everything is in TriState (also the RX/TX).
A timeout timer is reset with every character received. If the timoeut is reached programmer goes inactive (set programming pins to tri state) and enter USB-SERIAL mode. This then setups the RX/TX pins and from then on it is a USB-Serial device.
With a DTR this cycle can be started again, so no need to unplug the device which in practice is a real bonus.

If another programmer software is being used a different startup sequence is tested and that part of the software is activated. I also have this for the current measurement function. When this mode is entered a reading of the analog ports is send over USB which then can be stored or graphed.

When you just want to use it as a USB-Serial this startup sequence slows things down a bit. For that purpose i will add a detection of 0x0D to start that mode quickly.

Robert Rozee said
a useful debug tool would be that all characters received from the PC are still sent out the serial port, even if programming mode is engaged. futhermore, every character that programming mode wants to send back to the PC is also echoed out the serial port with bit 7 set. this would give you an ability to display a trace of any programming session (very similar to the one pic32prog produces when configured appropriately) on an attached terminal, and could be quite useful for debugging the programming of other PIC (non 32-bit) devices.

Yes this would be nice to have. I will add this once the USB-Serial/Programmer part is cleaned up.

Robert Rozee said
what extra commands did you need to add for programming the 1455?

I programmed that as a separate function, to not introduce errors in the existing PIC32 code. I left it out for now. It is better to reseach this a bit more as i suspect that a whole range of PIC's can be programmed similarly as a PIC16F1455 and that would be much more useful.

Rober Rozee said
btw, TZA: i really do recommend at least providing a single pin (if one is spare) to turn power to the PIC32 on/off, even if this feature requires an external switching transistor and is not connected/used. others may wish to use the feature, and having pic32prog able to control the power helps ensure that the PIC32 is prevented from running any code.

I considered this and did not do it because it seemed to be more open for user error.
I think there are two scenarios.
1 ) You just have a bare chip not part of a circuit. You wire this up on a breadboard or maybe use a zif socket. To get this to work you would connect the programming pins #MCLR,PGD and PGC and you feed it power from the 3v3 and GND. Having the PIC32 under power at that time does not matter as it is not connected to anything anyway.

2) The PIC32 is part of an existing circuit. Now here things get complicated as there are so many different situations possible. There is probably a ICSP connector and when you connect to this the VDD pin is the one that can give trouble. The #MCLS,PGD,PGC and GND are save to connect in all circumstances. It is in my opinion then better to feed power TO the USB-Serial module on its VDD pin. The user can then choose if this is either 5v or 3v3. The module also provide these voltages but they are not connected to the pic16f1455. This chip becomes active when either the 5v pin or the 3v3 pin is connected to the VDD pin. Also an existing circuit can provide power to this VDD pin controlling the signal levels. Putting a switch before the VDD pin will allow you to remove power from the pic16f1455 and thus also the USB connection is broken. Putting the switch back on will reconnect, this will helppreventing unplugging the USB all the time.

While i type this it makes even me confused

I think some examples in pictures will make it a lot clearer. I will do that soon.

Microblocks. Build with logic.

robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2285

Posted: 11:53am 27 Sep 2015

Copy link to clipboard

Print this post

serge has just updated the master repository at github with new executables for Win32, Linux, and OS X. the version number is now 2.0.174.

the latest release version of pic32prog can be downloaded from here:
https://github.com/sergev/pic32prog/raw/master/pic32prog.exe
(direct link to windows .exe)

pre-compiled versions for 32 and 64-bit linux, and mac OS X are also available at:
https://github.com/sergev/pic32prog

these replace all betas released prior to this posting

i have verified that Win32 and 32-bit Lunux versions are now fully functional, and that they include the reduction to 115,200 baud and 4-bit data compression necessary to work with the CH340G bridge on chinese Arduino NANO clones when using Linux.

below is the output from a run under 32-bit Linux Mint:

user@eM350-mint ~/Downloads $ ./pic32prog -d ascii:/dev/ttyUSB0 MM47B32.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: (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: 2141 bytes per second

total TDI/TMS pairs sent = 3196301 pairs
total TDO bits received = 501584 bits
total ascii codes sent = 1004687
total ascii codes recv = 172442
maximum continuous write = 452 chars
O/S serial writes = 97267
O/S serial reads (data) = 15682
O/S serial reads (sync) = 10
XferFastData count = 58902
10mS delays (E/X/R) = 8/0/0
elapsed programming time = 2m 02s
user@eM350-mint ~/Downloads $

cheers,
rob :-)

MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209

Posted: 02:27pm 27 Sep 2015

Copy link to clipboard

Print this post

Great!
Tested it with the 1455 and can confirm it works.
[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]

I am puzzled though by the numbers. The totals seem to be much higher. I used the same hex file, i think. It is from the latest beta version and size of the hex file is 737,236 bytes.

Microblocks. Build with logic.

robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2285

Posted: 04:49pm 27 Sep 2015

Copy link to clipboard

Print this post

that puzzled me a bit too, but i think i've worked it out. have just gone back over the thread and picked up the output from several of your earlier runs as you optimized the code:

Posted: 20 September 2015 at 5:26am
Version 2.0.BETA (30-08-2015)
Data: 258712 bytes
total TDI/TMS pairs sent = 3304781 pairs
XferFastData count = 58606
elapsed programming time = 2m 14s
----------------------------------------
Posted: 20 September 2015 at 4:46pm
Version 2.0.BETA (30-08-2015)
Data: 258712 bytes
total TDI/TMS pairs sent = 3480420 pairs
XferFastData count = 58606
elapsed programming time = 1m 12s
----------------------------------------
Posted: 22 September 2015 at 8:31am
Version 2.0.BETA (2015-09-21)
Data: 258712 bytes
total TDI/TMS pairs sent = 3771166 pairs
XferFastData count = 58606
elapsed programming time = 0m 34s
----------------------------------------
Posted: 28 September 2015 at 12:27am
Version 2.0.174
Data: 258692 bytes
total TDI/TMS pairs sent = 3723775 pairs
XferFastData count = 58902
elapsed programming time = 0m 35s

so the file size is not changing, and the quantity of data written to flash (roughly proportional to XferFastData count) is also remaining the same, while the quantity of chatter between pic32prog and the target pic32 is going up.

the conclusion is that you are hitting a bottleneck in the speed of writing to the pic32's flash. there are a couple of places in pic32prog where there are loops that wait for a response from the pic32. if these loops run for less than 100 iterations, nothing is recorded. if they go over 100, then 10mS delays are inserted up to 500mS in total, and these (as X and R) are kept track of by pic32prog:
10mS delays (E/X/R) = 11/0/0

[0] E = delays in chip erase. 100mS typical, 1000mS upper limit
[1] X = delays inserted in xfer_instruction (after 100 loops)
[2] R = delays inserted in get_PE_response (after 100 loops)

the likely contender is in get_PE_response (R). the PE handles the writing to flash. i shall need to investigate further to find out how many sub-100 iterations are actually occurring.

cheers,
rob :-)Edited by robert.rozee 2015-09-29

MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209

Posted: 05:10pm 27 Sep 2015

Copy link to clipboard

Print this post

When compared to your output with using the Nano it seems that there is way more data sent over the usb then would be necessary.
[code=Nano]
total TDI/TMS pairs sent = 3196301 pairs
total TDO bits received = 501584 bits
total ascii codes sent = 1004687
total ascii codes recv = 172442
[/code]
[code=pic16f1455]
total TDI/TMS pairs sent = 3723775 pairs
total TDO bits received = 957768 bits
total ascii codes sent = 1190023
total ascii codes recv = 329262
[/code]
About 500.000 TDI/TMS pairs more and 185000 more ascii codes.
This would suggest there is still something to optimize.
Not so much speed as that is satisfactory already.
Minimizing the amount of communication probably also equals less change of failure.
Are those mostly 'retries' to read a response from the PE?
Because if that is the case inserting a few nops() at the right spot might be better.

Microblocks. Build with logic.

robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2285

Posted: 01:08am 28 Sep 2015

Copy link to clipboard

Print this post

ok, have just run some checks and done the maths.

first off, using my setup of a NANO, winXP running on a 1.3GHz ATOM netbook (EM350), there are 4747 calls to get_PE_response (in "adapter-bitbang.c") while programming and verifying MM47B32.hex. and within get_PE_response, there are 9496 passes through the 'ready' loop waiting for the pic32.

so, on average, the 'ready' loop is passed through 9496 / 4747 = 2.0 times for each call to get_PE_response. in fact the routine is called twice as often during verify than during writing to flash, while most (not all) calls while writing to flash only pass through the loop once. but get_PE_response has no knowledge of where it is being called from, so can not change its behaviour accordingly.

now, working with the numbers from your above post:

3723775 - 3196301 = 527474. divided by 37 pairs = 14256.1
(1455) - (NANO)
957786 - 501584 = 456202. divided by 32 bits = 14256.3

each status request consists of 32 bits of output data + a 3-bit header + a 2-bit footer = 37 pairs, while 32 bits are returned as the status. this equates to approximately 14256 passes through the loop. 14256 / 4747 = 3.0

this leads to the conclusion that with a NANO the 'ready' loop is run through an average of about 2 times per call to get_PE_response, while with a 1455 it is run through about 5 times per call. unfortunately these numbers are only averages, and it is quite conceivable that there could be quite a large variance seen in practice. in particular, even using a 1455 as the programming head, single passes through the loop could well be common.

in short, i can't see any sensible way of building in a fixed 'fudge factor' delay.

cheers,
rob :-)Edited by robert.rozee 2015-09-29

MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209

Posted: 02:52am 28 Sep 2015

Copy link to clipboard

Print this post

Thanks for doing the math.
I tried adding some nops, but that did not reduce the numbers also.
Oh well. If it works don't fix it.

Microblocks. Build with logic.

Spacedementia87
Newbie

Joined: 03/08/2016
Location: United Kingdom
Posts: 26

Posted: 11:38pm 27 Sep 2016

Copy link to clipboard

Print this post

Right I seem to be having an issue.

I have successfully initialised the arduino nano:

./pic32prog/linux64/pic32prog -d ascii:/dev/ttyUSB0 -b3
Programmer for Microchip PIC32 microcontrollers, Version 2.0.204
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

However, when I then connect it up to the microchip, I cannot seem to get the firmware written:

./pic32prog/linux64/pic32prog -d ascii:/dev/ttyUSB0 ./Micromite_5.2.hex
Programmer for Microchip PIC32 microcontrollers, Version 2.0.204
Copyright: (C) 2011-2015 Serge Vakulenko
(ascii ICSP coded by Robert Rozee)

Adapter: . OK1 OK2 - ascii ICSP v1E

No target found.

I have checked the whole circuit!

I cannot figure out what is going wrong.

The chip is not in a circuit at the moment, so I have a TC1264 providing it 3.3v. Is that right?

I basically have the mx170f258b in a circuit like it is shown in the micromite forum and then the nano shown as it is in this diagram:

with the two connected on a common row on the breadboard.

I have used a continuity checker to test the links between the datalines on the nano and the correct pins on the chip.

Any help would be greatly appreciated.

MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209

Posted: 11:55pm 27 Sep 2016

Copy link to clipboard

Print this post

Don't forget the capacitor on the VCAP pin to ground.
Without it it does not work.

Microblocks. Build with logic.

Spacedementia87
Newbie

Joined: 03/08/2016
Location: United Kingdom
Posts: 26

Posted: 01:18am 28 Sep 2016

Copy link to clipboard

Print this post

MicroBlocks said Don't forget the capacitor on the VCAP pin to ground.
Without it it does not work.

Yes, I have a 47uF Tant capacitor between pin 19 and 20.

Spacedementia87
Newbie

Joined: 03/08/2016
Location: United Kingdom
Posts: 26

Posted: 01:49am 28 Sep 2016

Copy link to clipboard

Print this post

I solved it!

Continuity tester showed me I had a dodgy line on my bread board!

panky

Guru

Joined: 02/10/2012
Location: Australia
Posts: 1094

Posted: 01:08pm 02 Oct 2016

Copy link to clipboard

Print this post

@TZ & Rob,

This is amazing work you guys are doing and makes my head hurt just trying to follow☺☺ -thanks for sharing.

@TZ - I have several of Peter M's 470 boards with the 1455 option. I have not yet installed the 1455's as I am unsure of how it will all work to program the 470?

Also, does the work you are doing on the thread above with updated versions of the software in the 1455 apply to the 1455's you have previously supplied to me? If so, how should I re-program my 1455s?

Lastly, do you have a general description of the operation and use as a programmer for your 1455 when used in Peter M's 470 board (maybe this should be sent to Peter M?)

Thanks again,
Doug.

... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it!

MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209

Posted: 09:03pm 02 Oct 2016

Copy link to clipboard

Print this post

Doug,

The 1455 you've got are capable of USB-Serial and programmer for the PIC32 range of chips.

On Peters board it allows you to switch between 'modes' by using a little tactile switch. Those modes are either 'USBSERIAL' or 'PROGRAMMER'. This will also be indicated by the LED.
For programming the 470 you first put the chip in 'PROGRAMMER' mode and then use PIC32PROG to actually program the 470. You will need to tell PIC32PROG which COM port to use and which hex file.

A few posts before this i showed a screendump of a PIC32PROG session that includes the command line needed at the top.

Microblocks. Build with logic.

centrex

Guru

Joined: 13/11/2011
Location: Australia
Posts: 320

Posted: 10:21pm 02 Oct 2016

Copy link to clipboard

Print this post

A question perhaps for Rob or TassyJim is this latest version of the pic32 programmer software compatible with the wrapper that Jim presented some time ago that allowed a pic32 170 to program other pic chips.
Regards
Cliff

Cliff

TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5882

Posted: 10:59am 03 Oct 2016

Copy link to clipboard

Print this post

centrex said A question perhaps for Rob or TassyJim is this latest version of the pic32 programmer software compatible with the wrapper that Jim presented some time ago that allowed a pic32 170 to program other pic chips.
Regards
Cliff

I now have some chips to play with but I still haven't found time to put one together.
It should be easy enough to incorporate.

Jim

VK7JH
MMedit MMBasic Help

Page 4 of 4

Print this page

To reply to this topic, you need to log in.