Inchworm/Firefly with 12F629/675

[toodles]

On Monday I received my package from dipmicro and futurelec together, including everything needed for assembling both Inchworm and Firefly. The assembly was pretty good (Bill, please widen the holes for the ZIF, and maybe change the layout of the transistors to a striaght line, but other than that, pretty easy).

Setting up the debugger took a few tries, but in the end, I have successfully ran both of the test 16f88 tutor programs (the one that does nothing but loop so you can see the button changes on the watch'ed PORTB, and the blinky88).

Now I want to get to some other projects and burn some hex files for either the 12f629 or 12f675. This has met with no success. In fact, it has met with no success programming any chip in the ZIFF socket. I'm hoping this is a simple oversight of mine somewhere, but Im stumped.

My problem goes like this:
I want to program a chip, let's start with one of the 8 pin jobs (12f629 and 12f675; tested with 3 different 629 chips, and one 675 chip), so I set the DIPs on the firefly to all off, except for the last '8/18 pins' switch. Firefly is connected with short ribbon cable to the Inchworm, Inchworm is powered froma 12v wall-wart, green lights on both boards. 8 pin chip is inserted into ZIF with pin 1 of the PIC at pin 11 of the ZIF. (pin 2 at pin 12, 3 @ 13, 4 @ 14, and whatever the opposite is- no, I dont think I put it in 180 degrees from correct

Inside MPLAB, Configure->Set device ->12f629. Select programmer as ICD2, and Connect.

The result is always identical to this, (except the expected device id, but 0x0 is always the byte read)

Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to target
ICDWarn0020: Invalid target device id (expected=0x91, read=0x0)
...Reading ICD Product ID
Running ICD Self Test
...Passed
...Download Operating System Succeeded
Setting Vdd source to target
ICDWarn0020: Invalid target device id (expected=0x91, read=0x0)
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready

After failing wiht the 8 pins, I also tried a 16F88 (18 pin) and a 18F4455 (40 pin), changing the number of pin's DIP as appropriate and running through the same steps as above; all read 0x0 bytes, and if the chip used an OSCCAL, readding 0x0 for it as well when connecting. Yes, MPLAB downloaded a new operating system when the chips were changed to different packages.

To make matters even worse, if I disable all of the DIP's but the Tutor one, it connects and identifies the 16F88 in the tutor circuit just fine. I have been leaving the tutor 16f88 in the IC socket, assuming it would not interfere with programming; is this wrong?

I disconnected the ribbon cable from the firefly, and used a multimeter to test continuity from all of the pin pairs to the matching 8 pin connections on the ZIF; all 5 were present.

Any help would be greatly appreciated.

 

[toodles]

Well, I got it working by holding down the reset button on the firefly for the entire procedure. So I think I got that part down. A couple of questions about the board though:

1. Do I have to keep reset held the entire time?
2. Does the 'Hold in Reset' and 'Release from Reset' buttons in MPLAB not do anything?
3. Is there a way to modify things so I don't have to hold it down?
4. Can I get any information on how to modify the Inchworm to allow for reading and reprogramming of the 629/675 when the MCLR pin has been set for an input? Its was described in the following link, but without any details: **broken link removed**
5 Any cheap way of getting the new Inchworm+ for a customer who bought a full kit less than a week ago

 

[Pommie]

If the on-board 16F88 has a program in it that switches portb to output it will stop the other chip from being programed. I would try it without the on-board 16F88.

Mike.

 

[geko]

4. Can I get any information on how to modify the Inchworm to allow for reading and reprogramming of the 629/675 when the MCLR pin has been set for an input? Its was described in the following link, but without any details: **broken link removed**

The Inchworm mod' to control the 5 volt supply that you saw on my web site is as follows.

You need to cut a couple of tracks on the Inchworm PCB as shown in this thread.

https://www.electro-tech-online.com/threads/inchworm-1-5-reed-relay-mod-switched-5v-on-target.26984/

Then I added the mod' shown in the attached file to the Inchworm.

MPLAB still warns about programming 12F675 with MCLR as input but if you continue it programs it correctly.

Well, I got it working by holding down the reset button on the firefly for the entire procedure. So I think I got that part down. A couple of questions about the board though:

I also had the same issue with the Firefly and the 16F88 as you did, I just run it without the 16F88 in unless I actually want to do something with it.

 

[toodles]

MPLAB still warns about programming 12F675 with MCLR as input but if you continue it programs it correctly.

I managed to program the 675 with the reset button held down, even after the MCLR warning. If I do this mod, will it allow the chip to be read and reprogrammed again after its programmed?

 

[geko]

I've been having a play with my Firefly board this morning.

Without any 16F88 in the tutor socket, I put a new 12F675 in the ZIF socket which MPLAB identified and read back.

I then powered it all down and put a 16F88 in the tutor board, turned off Vpp to the tutor socket on the DIP switch.

Then I powered up the Firefly board and attempted to read back the 12F675 but MPLAB couldn't even identify the device.

I then disconnected the Firefly from the Inchworm and attempted to read the 12F675 in a board with ICSP connections and it still couldn't ID the 12F675.

Ignoring the error about it being unable to identify the device I programmed it with some code. It gave an error about having an invalid OSCCAL instruction, which I ignored and let it program the device any way.

Having done that, I clicked on the "Reset and Reconnect to ICD" button and it then indentified the 12F675 correctly and read it back, although the OSCCAL word was erased.

What I think is happening is this, but others may want to verify my findings.

The 16F88 supports LVP (low voltage programming mode) and it is enabled in a new device until the config word is programmed to disable it ( _LVP_OFF in the config word)

In section 15.18 of the 16F88 datasheet it states that RB3 should not be left floating when configured for LVP but must be held low. If it does float high then it enters programming mode and I think this is happening since, if you look at the Firefly schematic, RB3 goes to CON4 the servo/LED/IO connector and is not pulled up or down.

Since the ICSP DAT/CLK signals from the Inchworm connect to both the 16F88 and ZIF socket at all times, corrupt data appears on the DAT signal as both devices enter programming mode, and this is causing the 12F675 to get erased / corrupted.

So I'd suggest that if you want to leave the 16F88 on the Firefly all the time, you need to:
a) add a pull-down to RB3
b) make sure any code you have in the 16F88 leaves RB6/7 set to input.

Anyone else have thoughts on this.

 

[blueroomelectronics]

Well, I got it working by holding down the reset button on the firefly for the entire procedure. So I think I got that part down. A couple of questions about the board though:

1. Do I have to keep reset held the entire time?
2. Does the 'Hold in Reset' and 'Release from Reset' buttons in MPLAB not do anything?
3. Is there a way to modify things so I don't have to hold it down?
4. Can I get any information on how to modify the Inchworm to allow for reading and reprogramming of the 629/675 when the MCLR pin has been set for an input? Its was described in the following link, but without any details: **broken link removed**
5 Any cheap way of getting the new Inchworm+ for a customer who bought a full kit less than a week ago

Hmm, this happens sometimes when the 16F88 on the tutor is not blank.

1. dip settings for 8 pin dddddu (will disable mclr)
2. make sure _debug_on is part of your config setting
3. erase the 16F88 always works
4. The ICD2 & MPLAB will warn whenever you try MCLR as I/O (input)
5. Inchworm+ has the switch for target +5 switching, MPLAB still gives the warning though

Here's the cutting part of the mod, I'll look for the rest of the post (it was posted in these forums so a quick search should find it for you)

I've attached the first relase of the new Inchworm+ assembly manual, it has the BS250 PFET version of the VDD switch (200ma)
**broken link removed**

 

[toodles]

Well, I havent made the changes yet; I'll save it for another day.

Sadly, now the Inchworm is completely unresponsive. All of the following is with the firefly completely disconnected from the inchworm. MPLAB IDE constantly says 'Unable to connect'. This is with two different systems (both have the Hardware buffers disabled from Device Manager), and two different serial cables.

I took out the 16f877 and put it in my cheapo JDM programmer. It was read and appears fine (Did you know the string 'All Your Base Are Belong To Us' is in the downloaded ICD2 firmware? Funny guys.) but just to be safe, I reflashed it with the 877 bootstrap firmware, the BL010101.HEX that was in the MPLAB directory of my install. Still, no change. None of the components have obviously blown. When powered, green LED is on as normal. Multimeter showed the voltage converter working fine, from the 12v wall wart to the 5v output, and the 877 is getting clean power on both power and both ground pins.

Opening up the COM port in hyperterminal isn't showing anything; characters go into oblivion with nothing echoed back.

Is there any way to test the 232 serial chip? Are there any other tests or suggestions for troubleshooting this?

 

[blueroomelectronics]

One way to "test" the ST232 is the VPP test. The internal doubler is running if you get better than 12V at the VPP test point.

The crystal can be tricky, keep a tiny amount of space between it and the PCB. (paper thickness)

You could also remove the 877 and short the TX&RX pins (on the 877 socket) then try hyperterminal.

What sort of com port is it? Some USB to RS232 have trouble.

 

[toodles]

One way to "test" the ST232 is the VPP test. The internal doubler is running if you get better than 12V at the VPP test point.

The crystal can be tricky, keep a tiny amount of space between it and the PCB. (paper thickness)

You could also remove the 877 and short the TX&RX pins (on the 877 socket) then try hyperterminal.

What sort of com port is it? Some USB to RS232 have trouble.

Both serial ports are built in, not USB (one is on a laptop port replicator, the other on the desktop motherboard).

Both tests seem to say the 232 gave up the ghost. Voltage at the VPP TP is 0, (and .05 on the other side of that diode), and when I short the TX and RX pins (25 and 26), hyperterminal again doesnt echo anything back. Looks like Im buying a new 232, unless there are other places I should check first. Thanks for helping me verify.

 

[Ayne]

https://www.electro-tech-online.com/threads/some-question-about-inchworm.28015/
https://www.electro-tech-online.com/threads/icd2-operating-system.28042/
https://www.electro-tech-online.com/threads/first-program-in-assembly-and-programmer-inchworm.28068/

 

[toodles]

Well, news only of slight success. I received a replacement ST232BN in the mail from Digikey today and swapped it in. When attempting to "Download ICD2 Operating System", the busy light comes one, things are looking good, until the busy light goes out and MPLAB shortly thereafter reports that communication was lost.
Voltage at the vpp test point varies, but seems to be resting at about 8.5v. If the busy light is on when I try to download the ICD2 OS, then SOME sort of communication is going on, but I have no clue where to test where it's failing.

Is it possible to flash the 877 with the ICD2 OS .hex file directly in another programmer? Any other suggestions where I could test to get this thing running right?

 

[toodles]

Checked all of the pins in the ST232, and it looked like pin 16 (VCC) was getting -0.42v. Quick check showed it was not connected to the +5 line from the 7805; inspecting the soldering showed I either went way too fast on that pin, or missed soldering that pin altogether.

Stupid user error, of course, but it appears to be working solid now. Now to get used to using the debugger. Bill, keep the little firefly tutorial projects coming!

Thanks to all who've read and especially those who've tried to help.

 

[blueroomelectronics]

Cold solder joints are a common problem, glad you got it working.

Here's a quick Firefly program. LED2 will light red whenever it see a TV remote transmit.

;*** IR_Test.asm   DIP switch DDUUDD 
;*** Firefly IR in test   and/or push button 1 test (RB0)
  list    p=16f88         ; list directive to define processor
  include   <p16F88.inc>    ; processor   specific variable definitions
  __CONFIG _CONFIG1,   0x377C & _WDT_OFF
  org       0x000           ; reset vector
  bsf     STATUS,RP0      ; set to bank 1
  movlw   b'00111111'     
  movwf   TRISA           ;B1 set A7 & A6 as outputs for   LED2          
  bcf     STATUS,RP0      ; set to bank 0
  clrf      PORTA           ;B0 zero port   (LEDs off)
main    
  btfss     PORTB, 0        ;B0 is RB0   low?  (active)
  bsf     PORTA, 7        ;B0 if yes then LED2 on (Red)
  btfsc   PORTB, 0        ;B0 is RB0 high? (idle state via   pullup)
  bcf       PORTA, 7        ;B0 if yes then   LED2 off
  goto    main            ; loop forever
  END

 

[Mike - K8LH]

How does it do that Bill? Is there an IR detector/decoder chip on that board Sir?

 

[William At MyBlueRoom]

How does it do that Bill? Is there an IR detector/decoder chip on that board Sir?

Why of course there is an ir detector on firefly. The tsop1138 is a 38khz ir sensor, it even has the proper supply decoupling on firefly. It is enabled by sw5-3.

I thought you had a firefly Mike.

 

[Mike - K8LH]

I do have a FireFly but I haven't downloaded the manual or started to put it together yet. Also a little low on parts right now but I do have a TSOP1138. I ordered it about a month ago and I was planning to develop a simple background ISR driver to decode 12/15/20 bit SIRC codes.

 

[Nigel Goodwin]

I do have a FireFly but I haven't downloaded the manual or started to put it together yet. Also a little low on parts right now but I do have a TSOP1138. I ordered it about a month ago and I was planning to develop a simple background ISR driver to decode 12/15/20 bit SIRC codes.

My SIRC's routines are software only, but someone converted them to interrupt driven and emailed them to me, if you like I could send you a copy?.

 

[blueroomelectronics]

I'd like a copy of those IR routines.