Matrix user forums

I have a new Multiprogrammer, LED board and flowcode.

I have installed all the software as recommended and have successfully written a simple flowcode program, which runs fine in simulation.

I have connected the multiprogrammer - complete with 16F88 as delivered - to a 13.5V DC supply, have set the relevant jumpers to USB (not ICD2) and to PSU (not USB)

When I try to compile to chip from flowcode, I get the following errors :
'Could not ID the onboard chip ...... ' to which I reply OK. and
'PIC Micro has not been erased, OK to continue' to which I also reply OK.

The final message in the programming window is ..
Programming failed: <config1> & <config2>
That took 47.609 seconds
Erasing the PICmicro
Programming failed:

Any thoughts anyone?
Attached is a copy of the advanced confic screen for the chip.

Hello

Please can you confirm that there is only one chip plugged into the Multiprogrammer board and that it is the correct way round etc, This has been the reason for similar problems in the past. The only other chip that should be present on the board is the U1 USB chip.

Do the green and orange LEDs light up?

I had exactly the same error message when I first tried to id the 16F88. I think I solved it by moving the switch from XTAL to RC. Perhaps the 16F88 doesn't support XTAL mode? Anyway, I also noticed that the red LEDs were running a pattern as if the chip was already running a program. I guess that was normal behaviour; a test program?

Anyway, hope this helps.

John

Thanks for the replies.
I will check on Monday - however the multiprogrammer is exactly as sent - I simply removed it from the box, checked the jumper settings and plugged it into a power supply.
I doubt if there is more than one chip on there, as they would have been put there by yourselves.
Can you confirm the power supply connections - exactly where should the 13.5 be connected ( I am using the screw terminals )? I only recall seeing one led come on on the board when I power this up.

Hello

Power can be applied through the J6 DC connector or via pins GND and +14V of the screw terminals. Polarity going into J6 is not important thanks to the bridge rectifier.

One Green LED should come on to signify power, The Orange LED should come on to signify USB and if you connect a LED E-Block to PortA or PortB and move the oscillator switch to either RC FAST or XTAL (Not sure what the default prog is set to use - Probably RC FAST) then you should see the LEDs light up in sequence.

Aha, I had the power going into the V+ screw terminal - I assumed the +14V terminal was an auxiliary output.

I will test the new setup later - is putting 13.5V into the V+ terminal likely to have damaged the board?

Unfortunately, nowhere in the documentation can I see the fact that the power has to go IN on the +14V pin. If you could point this out to me, I will highlight it for others. I have the EB006-00-5 Technical datasheet - dated 2005.

Cheers

Hello

Hm im not sure, doing that has applied 13.5V to all of the 5V circuitry. Its likely that the 16F88 chip will have been damaged by the 13V. Whether the multiplexers etc will make it out alive only time will tell.

A new board works with the new power connections- although the original one now won't program. I assume something has failed due to the incorrect power connection.

I have a supplementary question now I am going ...

I have written a simple nested loop to count down from 65535 to zero using two variables. Flowcode2.fcf attached.

When stepping through the flowcode, I output the count to PORTB, but then after the complettion of the next command - which is a delay - PORTB goes off ( i.e. all bits to 0 ) until I send the next count to it on the next iteration of the loop.

Can you help please - It seems to work fine when running on the Microprogrammer - but I am disconcerted by the apparent disparity.

Hello

Your program seemed to be doing a few strange things. I have attached a copy of how I would do the program using two count variables. I do see what you mean about the simulation though not seen a bug like that before. I will pass it onto the Flowcode engineer who should be able to help find the root of the problem.

Hello

Found the problem. In your Flowcode program you have a switch component that is connected to PortB. This is acting to pull the outputs low after the output command. To find the hidden components attached to your program goto View -> Attached Components. Deleting the switch component allows the simulation to run as expected.