Sign in

username:

password:



Not a member?

Search piclist



Search tips

Subscribe to piclist



piclist by Keywords

12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx

Discussion Groups

Discussion Groups | Piclist | Wisp628 and Bumblebee or Winwisp

A discussion group for the PICMicro microcontroller. Also called the Microchip PIC, this list is dedicated to the use and abuse of this fine, simple, microcontroller. Close to topic posts are welcome, ie. general electronics.

Wisp628 and Bumblebee or Winwisp - tadaosystems - Jan 14 0:12:00 2004


I recently picked up a Wisp628, which works wonderfully (Thanks
Wouter van Ooijen!). However, I've run into a problem with one of my
designs, and I'm not sure if it's something I've set up incorrectly
with my circuit, or if it's in my code.

I have a device that is set to sleep as soon as power is applied. A
momentary switch is then used to trigger an interrupt that turns the
board on and off. It functions perfectly, I just can't seem to use
the Wisp628 with it.

When I try to use Bumblebee it will recognize the mcu (a 16F627), but
after that it will not allow me to read or write to the chip. If I
have it identify the chip again, it also fails. If I recompile the
code without the initial sleep instruction (which occurs after all my
initializations) it will allow me to program the chip without any
problems. I noticed that when you first attach the dil clip to the
mcu MCLR is held around 5 volts. If I have bumblebee identify the
chip, and then check the voltage again, it's sitting at 13 volts from
the Wisp628's charge pump. However, it just sits at 13 volts and
never comes back down. After that, if I try to identify the mcu
again it just says the target device cannot be identified. Same
error with a read or write.

I noticed if I set MCLREN it works fine even with the sleep call, but
unfortunately my circuit boards have already been made, and don't
have a way of keeping MCLR high when the Wisp628 is not attached to
the board, essentially disabling the whole board if I use MCLREN.

How come a sleep instruction causes it to mess up?




(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: Wisp628 and Bumblebee or Winwisp - Dave Mucha - Jan 16 17:39:00 2004

--- In , "tadaosystems" <flipflops67@h...>
wrote:
> I recently picked up a Wisp628, which works wonderfully (Thanks
> Wouter van Ooijen!). However, I've run into a problem with one of
my
> designs, and I'm not sure if it's something I've set up incorrectly
> with my circuit, or if it's in my code.
>
> I have a device that is set to sleep as soon as power is applied.
A
> momentary switch is then used to trigger an interrupt that turns
the
> board on and off. It functions perfectly, I just can't seem to use
> the Wisp628 with it.
>
> When I try to use Bumblebee it will recognize the mcu (a 16F627),
but
> after that it will not allow me to read or write to the chip. If I
> have it identify the chip again, it also fails. If I recompile the
> code without the initial sleep instruction (which occurs after all
my
> initializations) it will allow me to program the chip without any
> problems. I noticed that when you first attach the dil clip to the
> mcu MCLR is held around 5 volts. If I have bumblebee identify the
> chip, and then check the voltage again, it's sitting at 13 volts
from
> the Wisp628's charge pump. However, it just sits at 13 volts and
> never comes back down. After that, if I try to identify the mcu
> again it just says the target device cannot be identified. Same
> error with a read or write.
>
> I noticed if I set MCLREN it works fine even with the sleep call,
but
> unfortunately my circuit boards have already been made, and don't
> have a way of keeping MCLR high when the Wisp628 is not attached to
> the board, essentially disabling the whole board if I use MCLREN.
>
> How come a sleep instruction causes it to mess up? I'm not sure if you are having the problem of programming the chip
after the inital program, but the 8 pin chips have a little problem
with Vpp and Vdd. Evidently, Vpp must rise before Vdd or the chip
will not accept a program after the origional.

I have not confirmed this, but have been reading about it in the
Proton+ forum.

Dve






(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: Wisp628 and Bumblebee (figured it out) - tadaosystems - Jan 16 19:32:00 2004


I was having a problem with the programmer not being able to identify
the chip after the initial programmer choice, whether it be to
identify the chip, erase it, etc. To solve this I just had to set
the option bit MCLREN and make sure the MCLR pin was tied to vdd with
a resistor.

I'm still not sure why it programs fine with MCLRDIS as long as my
mcu never "sleeps". Ah well, not a big deal, and from what I've
read, the solution I found is the correct way it should have been
done from the beginning.

> I'm not sure if you are having the problem of programming the chip
> after the inital program, but the 8 pin chips have a little problem
> with Vpp and Vdd. Evidently, Vpp must rise before Vdd or the chip
> will not accept a program after the origional.
>
> I have not confirmed this, but have been reading about it in the
> Proton+ forum.
>
> Dve



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )