Need technical help from Microchip? Ask our Expert!

Hi, I`m not entirely sure where to start, but I have a reasonably old but Brand New! never used (until I had it a few weeks ago),  Microchip PICPAK II, 16C5x device programmer, dated Oct 26 1992, it has a PICPro II programmer in the box (and all the docs, chips, leads/adaptors and S/ware on 2 720k Floppies etc...)

I also have over 150 assorted 16c54s and 16c57s.

so Naturally I`m learning these 33 commands used and have already gotten the s/ware toolchain working propperly as well as the programmer (I use an old Win98 machine with DOS).

so all is GOOD! here

but there`s a snag, inside the device are 2x PIC16c57`s with the firmware to make the thing work, but these are JW chips (erasable)

that makes the data in their EPROM already 20 years old, this as you may be aware is about as far as eproms can reliably be trusted to maintain data integrity, so my aim is to Copy the firmware onto a OTP version, so the data will be there forever!

but I only have one device programmer/reader and it`s likely the Read Firmware fuses are set to make that impossible even if I could.

I have read on the microchip site that they even have one of these in their Museum! and as such have little to no data about them.

now I don`t know if you`re at all like me, but I think it would be a Terrible shame to let this device of mine become entirely useless simply because of time elapsed, and Not because of use.

so I need a favor please, can you dig out the Source code or even the hex code for these pair of EPROM PIC16C57s so that I can re-burn the data back on them and make them good for at least another 20 years!

(or more if I use the OTP versions).

I give you my Word as a Gentleman that I will not Share/Copy/or give this data to another soul, and will destroy it after I get these chips refreshed, you have my Word!

I`v brought back many "Vintage" computers this way in the past and enjoy doing it (and using them!), I seriously hope you share my enthusiasm in saving this machine, it`s really too nice to let it die.

All the best, and Thanks!

Hi , I remember the PICPRO II , nice metal case , well engineered but it only ever supported the orig 5X parts and it programmed the parts in parallel mode . The PICKit 3 offers so much more for a fraction of the cost so my suggestion would be to put the PICPRO II back into it's box and forget about it - if you really want to get it up and running please contact our Corporate Apps Team and if you can find anyone old enough to remember the PICPRO II they might be able to help you with this project - note that this is definitely an obsolete tool !!  Our Support Team can be found at www.microchip.com/support 

Cheers , Mike

Thanks! and sometimes I wish I was the sort of person that Could just put it back in the box and forget about it, sadly in this instance I`m not. it really Does seem such a nice piece of kit and built the way I like stuff built, to let it just "Die" in a box, besides, I can`t really hold "Old age" against it

I will try and contact these people you suggest and keep my fingers crossed (unless it makes my typing Too sloppy!)

I`m also wondering after reading your reply if you can help me a little (not in This thread necessarily) with some 16c5x code?

I`m trying a small production run of HEX in, to a single 7 segment display/decoder, basically to replace/replicate the MC14495 chip.

I have the lookup tables already drawn out and each will need a RETLW op code for each line I believe.

I have no idea how to read port A (the 4 bit port) as I want to use them as the Input lines.

so in effect, read the 4 bit binary data on port A and then use that as the offset to read the 7 seg LED code to output on Port B.

it Sounds quite simple, but I can`t help but feel I`m missing OPcodes that I need (I program in Z80 machine code), how do I read port A as a whole for instance?

I realise I`m a little off topic here, so I apologise to the other readers here, and thank them for their patience.

All the best!

I'm afraid that I'm not particularly technical - but the same tech guys can probably give you guidance on this . We do of course publish numerous applications notes:  http://www.microchip.com/wwwcategory/TaxonomySearch.aspx?show=Application%20Notes&ShowField=no

I'm sure you can find something here related to driving 7 seg displays . Cheers , Mike

Hi YT2095,

As Mike mentionned Microchip has lots of application notes which you can find here : http://www.microchip.com/appnotes

Additionally there are a couple of very nice manuals with lots of tips & tricks for PIC micros. I was reading them myself back a few days ago because some of the tips are real good ;=)

you'll find them here :

* http://ww1.microchip.com/downloads/en/devicedoc/40040b.pdf

and here :

* http://ww1.microchip.com/downloads/en/DeviceDoc/01146B.pdf

regards

Hi YT2095,

As Mike mentionned Microchip has lots of application notes which you can find here : http://www.microchip.com/appnotes

Additionally there are a couple of very nice manuals with lots of tips & tricks for PIC micros. I was reading them myself back a few days ago because some of the tips are real good ;=)

you'll find them here :

* http://ww1.microchip.com/downloads/en/devicedoc/40040b.pdf

and here :

* http://ww1.microchip.com/downloads/en/DeviceDoc/01146B.pdf

regards

Hello,

I use the Microchip USB starter kit II board with a PIC32MX795F512L. It appears that when I turn on the coprocessor in the Count mode to use it like a timer, it works until the program stop in a breakpoint. After that the, the program never jumps angain into the timer routine interuption... The coprocessor counter is still incrementing while the program is stopped. I haven't this problem with the simulator MPLAB SIM.

Perhaps this is due to the embedded debbugger on the USB starter kit board. Is it possible to avoid this issue by using a ICD3 ?

Is it possible to debbug the PIC32 while the coprocessor is used as an open core timer, or I need to use a standard timer instead ?

Regards

Hi,

The Coprocessor0 timer (count register) is running at half the PCU speed. It's a permanent free running timer (there is no way to stop it if the CPU is running unless you use debug register).

When you restart your SW it may happen that the count register has overflowed the compare register. In this case, it will only generate an interrupt after reaching 0xFFFFFFFF.

I made the experiment yesterday on my starterkit. Let's assume you run at 80MHz and you generate an interrupt every 1 ms with the coretimer.

It means you put 4.000.000 into the compare register.

When you stop the running program, when you restart your program the counter may have overflowed 4.000.000.

Let's take an example : let's imagine  counter register has reached 4.000.001 ( 0x3D 0901) when you restart.

To get the next Coprocessor timer, it will take ( 2^32 )    0x1 00000000 -  0x3D 0901 = 4.294.967.296 - 4.000.001 = 4.290.967.295 counts to reach interrupt.

The internal timer increments at half the CPU clock i.e every 25ns so it takes : 107 seconds (1mn 47s)

I did the experiment myself and in fact you'll see that interrupts restart after (maximum) a couple of minutes. It depens of your compare value and how long you waited before restarting your SW.

If you push RESET icon in MPLAB, you'll see that coprocessor timer interrupts operate as expected.

In the C32 compiler manual, you'll find at section 5.7.2.9.3 that the count bit in the debug register enable the user to control if count register continues incrementing or not during debug.

I did not experiment it but it should work ;=)

Regards

Ok thank you. I will try to configure the debug register...

I didn't wait so long to see if the timer reach the interrupt, but it seems logical.

Regards