Matrix user forums

Hi
This is a general question –
Is it recommended to remove the connected I/O devices before programming/reprogramming a PIC using the HP488v3?

I seem to have damaged two 12F675 by what appears to be reprogramming with I/O connected -making simple timing changes.

I ran a small test flashing LED program initially to ensure the PIC was working..

I then programmed the device with the required program and connected the I/O. This worked fine but then I tried to modify the program and the device seems to have died.

I can reprogram the device with the test program but there is no I/O activity.

I repeated the exercise on another new chip with the same outcome

Any clues?

Thanks.

I think I have answersed this myself ------ chip uses some of the I/O pins for programming.
Sorry should have thought of this

Hello,

The EB006 and HP488 boards have multiplexing technology that disconnects the programming pins from the surrounding electronics when programming so that there can be no interference.

My guess for the no I/O activity is that the hardware and software configuration specifically the oscillator are not setup to match each other. With the HP488 you generally want to use the HS oscillator type with watchdog disabled and then ensure the oscillator selection switch on the hardware is set to XTAL. The switches can sometimes stick a little bit so sliding to RC and then back to XTAL should fix this if this is the case.

Thanks for the response Ben.

The system is set to HS with the crystal selected and the watchdog is off.

Is there an explaination for this - I went back to check settings and repowered the board and the program started running - It was not running when I switch power off.

Then I attempted to load the main program - after several attempts of erasing and reloading - programming failed, I went back to the test program. I finally seemed to have success in loading the program but it would not run. I turned the power off for 8 hours reapplied power - the program in now running.

I do seem to have stability issues with the regulator overheating occassionally when using these chips - I have inserted a cap across the supply as recommended but occassionally it goes into melt down. If I remove power and reapply it will normally stabilse

Regards

Hi Terry,
What I find is if MCLR is enabled, then after programming just press reset button to restart device in the correct mode.
No need to disconnect and reconnect power.
Since disconnecting and reconnecting power will act as the same as pressing reset switch,
You program will then be working

Edit: I also find that with some target devices, I have to program them for the the second time for them to work.
If you see a pop up message stating 'Device not erased, do you want to continue?'
Then always select no as the device has not communicated properly, so will fail to program anyway.

Martin

Hi,

I am still having difficulties.

Pin 8 (Vdd) wrt power supply gnd shows random spikes upto 1.6 V o-p (I have a Picoscope Image but unable to attach picture)

Vss is a clean 5V dc.

Not sure what is going on but I dont think it would be overly healthy. Where does Vdd originate? Obviously it is not tied to gnd. Does the PPP firmware shunt connections based on the PIC selected for programming?

Any advice?

Thanks

TerryV

Hello Terry,

Vss is a clean 5V dc.

VDD pins should be at 5V with respect to ground
VSS pins should be 0V with respect to ground

VDD originates from the 7805 voltage regulator and may go to the target microcontroller via an P channel MOSFET.

PPP should be able to autodetect the device and then on this will swap in the correct erase, programming and config scripts.

Hi Ben,
Thank you for the response.

Appologies for getting my Vdd/Vss crossed. What ever happened to Vcc and Gnd?

But I still have the situation;

Pin 1 = clean 5Vdc
Pin 8 has spikes of varying magnitude but up to 1.6V at what appears to be 20 mS apart which seems to point to the 50Hz supply.

The 14V terminal is clean and sitting at 12.5 V and both +V terminals are at 5V and all are clean with respect to the GND terminal.

Do you think the spikes on pin 8 are the problem?

I have tried using a new chip and the same situation exists

Regards
TerryV