Searching \ for '[PIC] Trouble programming 16LF648A using Wisp628' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'Trouble programming 16LF648A using Wisp628'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Trouble programming 16LF648A using Wisp628'
2005\09\11@182633 by Carlos A. Marcano V.

picon face
Hi folks.

  I am trying to flash a 16LF648A using a Wisp628. First I use this:

C:\MCHIP\Blink>xwisp.py go uuu

  And I get this:

XWisp 1.08, command line mode
C:\Archivos de Programa\XWisp\serialwin32.py:88: DeprecationWarning:
integer arg
ument expected, got float
  win32file.SetCommTimeouts(self.hComPort, timeouts)
hardware: Wisp628 1.09 (fast)
target: 16f648a, revision 01 (ID=1101)
OK

Then, if I try to read the program from the chip, I get this:

C:\MCHIP\Blink>xwisp.py read 123
XWisp 1.08, command line mode
C:\Archivos de Programa\XWisp\serialwin32.py:88: DeprecationWarning:
integer arg
ument expected, got float
  win32file.SetCommTimeouts(self.hComPort, timeouts)
hardware: Wisp628 1.09 (fast)
target: 16f648a, revision 01 (ID=1101)
read Code 00B0Traceback (most recent call last):
  File "C:\Archivos de Programa\XWisp\xwisp.py", line 3563, in ?
    XWisp_Main()
  File "C:\Archivos de Programa\XWisp\xwisp.py", line 3560, in XWisp_Main
    Wisp_Line().Interpret()
  File "C:\Archivos de Programa\XWisp\xwisp.py", line 3180, in Interpret
    self.Execute( Command )
  File "C:\Archivos de Programa\XWisp\xwisp.py", line 3162, in Execute
    exec( 'self.CMD_' + Command.upper() + '()' )
  File "<string>", line 1, in ?
  File "C:\Archivos de Programa\XWisp\xwisp.py", line 2686, in CMD_READ
    self.CMD_GET()
  File "C:\Archivos de Programa\XWisp\xwisp.py", line 2586, in CMD_GET
    Ignore  = self.Purge )
  File "C:\Archivos de Programa\XWisp\xwisp.py", line 2204, in Read
    Data = self.Get_Cluster( Base )
  File "C:\Archivos de Programa\XWisp\xwisp.py", line 2069, in Get_Cluster
    D = int( Response[ 0 : 2 * self.Type.Stride ], 16)
ValueError: invalid literal for int():


And that happens with any program I try. This is the code:

list p=PIC16f648A
       #include "p16f648A.inc"

       __config _CP_OFF & _DATA_CP_OFF & _WDT_OFF & _BOREN_OFF & _PWRTE_OFF &
_INTRC_OSC_NOCLKOUT & _MCLRE_OFF & _LVP_OFF

       ERRORLEVEL        -224
       ERRORLEVEL        -302




#define        RED_LED                PORTB,5                ;O        



count1                        equ                0x20
count2                        equ                0x21
count3                        equ                0x22
dwell                        equ                0x23
tmp                                equ        0x26
tmp_addr                equ        0x36
tmp_data                equ 0x37


init
       clrf                STATUS
       bcf                STATUS,RP0
       clrf                PORTA
       movlw                0x07        ;off compare, enable pi
       movwf                CMCON
       bsf                STATUS,RP0
       movlw                b'11100100' ;0,1,4,3 output  2,6,5,7 INPUT
       movwf                TRISA

       bcf                OPTION_REG, NOT_RBPU        ;enable pullups

       bcf                STATUS,RP0
       clrf                PORTB
       bsf                STATUS,RP0
       movlw                b'01001111' ;  input  4,5,7 output  0,1,2,3,6 INput
       movwf                TRISB
       bcf                STATUS,RP0


;mem writing test
       bsf        RED_LED
       movlw        0x30
       movwf        dwell

test
       movlw        0x00
       movwf        tmp_addr
       movf        dwell,W
       call        writee

       bcf        RED_LED
       clrf        dwell

       movlw        0x00
       call        readee
       movwf        dwell

loop
       
       call        delay_on1
       bsf        RED_LED
       call        delay_on1
       bcf        RED_LED
       goto        loop


writee
       movwf        tmp        
       bsf        STATUS,RP0
       movwf        EEDATA
       bcf        STATUS,RP0
       movf        tmp_addr,W
       bsf        STATUS,RP0
       movwf        EEADR
       bcf        STATUS, RP0


ee_write
       bsf        STATUS, RP0
       bsf        EECON1,WREN
       bcf        INTCON,GIE

       btfsc        INTCON, GIE
       goto        $-2

       movlw        0x55
       movwf        EECON2
       movlw        0xAA
       movwf        EECON2
       bsf        EECON1,WR
       bsf        INTCON,GIE
ee_writewr
       bsf        STATUS, RP0        ;added
       clrwdt
       btfsc        EECON1,WR
       goto        ee_writewr

       bcf        EECON1,WREN
       bcf        STATUS, RP0        ;added        
       movf        tmp_addr,W
       call        readee
       subwf        tmp,W
       skpnz
       return
       bsf        STATUS,RP0
       goto        ee_write


readee
       bsf        STATUS,RP0
       movwf        EEADR
       bsf        EECON1,RD
       movf        EEDATA,W
       bcf        STATUS,RP0
       return

delay_on1
       movf        dwell,0
       movwf        count2
loop_on1
       call        one_ms_delay
       decfsz        count2,1
       goto        loop_on1
       return

one_ms_delay
       decfsz        count1,1
       goto        one_ms_delay
       return
       
       end

It is just something I found on the net and I was using it just to test
the Wisp628. Any ideas what could be happening?

Regards,
*Carlos Marcano*
-Guri, Venezuela-

2005\09\11@192310 by Jan-Erik Soderholm

face picon face

Carlos A. Marcano V. wrote :

> Hi folks.
>
>    I am trying to flash a 16LF648A using a Wisp628. First I use
this:
>
> C:\MCHIP\Blink>xwisp.py go uuu
>
>    And I get this:
>
> XWisp 1.08, command line mode
> C:\Archivos de Programa\XWisp\serialwin32.py:88:
DeprecationWarning:
> integer arg
> ument expected, got float
>    win32file.SetCommTimeouts(self.hComPort, timeouts)
> hardware: Wisp628 1.09 (fast)
> target: 16f648a, revision 01 (ID=1101)
> OK
>

Hi !

Not sure what problems you have (with my little
knowledge of Python, it sounds as some internal
Python script error), but do take a look at XWisp2
at http://www.robh.nl. It's smaller, faster at least on my
800 Mhz box) and easier to use (mainly the install).

Jan-Erik.



2005\09\11@202708 by Chen Xiao Fan

face
flavicon
face
I think the problem is the internal MCLR and internal OSC.
You need Wouter's dongle for this kind of device (they
need Vpp before Vdd). I hit this bug when I was testing xwisp2
v170 Linux version very recently.

PICkit 1 and PICkit 2 handles this slightly better when the chip
is off-line since it can control the sequence of Vdd and Vpp.
For Wisp628, the Vdd is always there since Vpp is generated from
Vdd. It would be better to add a line to control the Vdd sequence.
One more transistor and several resistors and a slightly change of
the firmware are needed.

If the chip is on board and the target is already power up, then
there is no elegant solutions for any programmers. One have to
power down the chip first.

By the way, Xwisp2 is a better host software for Wisp628.
It now supports Linux, Windows and OS/2
xwisp2 v170 can be downloaded from http://www.robh.nl.

Regards,
Xiaofan

-----Original Message-----
From: Carlos A. Marcano V. [spam_OUTc.marcanoTakeThisOuTspamgmail.com]
Sent: Monday, September 12, 2005 6:27 AM
To: Microcontroller discussion list - Public.
Subject: [PIC] Trouble programming 16LF648A using Wisp628

list p=PIC16f648A
       #include "p16f648A.inc"

       __config _CP_OFF & _DATA_CP_OFF & _WDT_OFF & _BOREN_OFF & _PWRTE_OFF
&
_INTRC_OSC_NOCLKOUT & _MCLRE_OFF & _LVP_OFF

2005\09\11@210103 by Carlos A. Marcano V.

picon face
Chen Xiao Fan wrote:

>I think the problem is the internal MCLR and internal OSC.
>You need Wouter's dongle for this kind of device (they
>need Vpp before Vdd). I hit this bug when I was testing xwisp2
>v170 Linux version very recently.
>  
>
 I will try to make the dongle and test.

>By the way, Xwisp2 is a better host software for Wisp628.
>It now supports Linux, Windows and OS/2
>xwisp2 v170 can be downloaded from http://www.robh.nl.
>  
>
 I downloaded the executable for xwisp2 from http://www.robh.nl and
tried it but all I got was:

C:\xwisp2>xwisp2w go prg.hex
xwisp2 version 1.7.00 (Sep 10 2005, Open Watcom C 1.30)
File prg.hex loaded and is Intel Hex format conforming

And I had to use ^C to finish the endless loop. Did you have any
trouble like this too?

Regards,

*Carlos Marcano*
-Guri, Venezuela-

2005\09\11@213921 by Chen Xiao Fan

face
flavicon
face
Yes I had the same problem. I think the problem will be
solved once you have the dongle. The problem is that
the chip will fail to go into programming mode since
Vdd is before Vpp. However xwisp2 should probably time
out and not staying there. I will check with
the author about this again. I will also make this dongle
and try it as well but I do not quite like this idea
especially for off-line program. (Take note Wisp628 is
designed to be a on-line ICSP programmer.) I think to add a
Vdd-target and Vpp-target and using two port pins like
PICkit 1/2 will be better option. Anyway maybe we need
to wait Wouter to release Wisp648 or Wisp2550 for this
to happen. ;)-

Regards,
Xiaofan

{Original Message removed}

2005\09\11@215904 by Carlos A. Marcano V.

picon face
By the way, I just tried to flash an oldie 16F84A with the simple b84a-2.hex file (blink-a-led sample for 84A from Wouter´s page)| and got this for answer:
|
C:\MCHIP>xwisp.py target f84a go a2.hex
XWisp 1.08, command line mode
Traceback (most recent call last):
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 3563, in ?
   XWisp_Main()
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 3560, in XWisp_Main
   Wisp_Line().Interpret()
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 3180, in Interpret
   self.Execute( Command )
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 3162, in Execute
   exec( 'self.CMD_' + Command.upper() + '()' )
 File "<string>", line 1, in ?
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 2589, in CMD_GO
   self.CMD_LOAD()
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 2612, in CMD_LOAD
   self.Image.Read( File )
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 300, in Read
   Address = int( Line[3:7], 16 )
ValueError: invalid literal for int():

Not encouraging, eh?

Then I tried it with the Xwisp2 but got the same problem as when I tried with the other chip: the program just hanged and I had to terminate it.

Regards,

*Carlos Marcano*
-Guri, Venezuela-

Chen Xiao Fan escribió:

{Quote hidden}

>

2005\09\11@221441 by Chen Xiao Fan

face
flavicon
face
Where do you get your Wisp628? Have you successfully program a
chip using it? I think you need to check the hardware.
I am not an expert in troubleshooting Wisp628 so I will leave this to Wouter. I only used xwisp (python) for a few times on Linux. I mainly use xwisp2 (C based) but I do not have the old 16F84A chip.

Regards,
Xiaofan

{Original Message removed}

2005\09\12@022511 by Jan-Erik Soderholm

face picon face
Carlos A. Marcano V. wrote :

> I downloaded the executable for xwisp2 from http://www.robh.nl and
> tried it but all I got was:
>
> C:\xwisp2>xwisp2w go prg.hex
>  xwisp2 version 1.7.00 (Sep 10 2005, Open Watcom C 1.30)
> File prg.hex loaded and is Intel Hex format conforming

What COM port is the Wisp628 connected to ? COM1 ?
What Windows version ?
Have you been able to get *any* communication to the Wisp628 ?

When I've had a "locked" PIC (due to int-MCLR enabled), I get an
error message saying something about the PIC not beeing found in
the config table, or something like that.

> And I had to use ^C to finish the endless loop. Did you have any
> trouble like this too?

I've never had Xwisp2 hang like that, it always gives some error
message end exists.

My guess is that you have some problem with your Wisp628
hardware that makes both XWisp and XWisp2 having troubles...

Jan-Erik.



2005\09\12@124506 by Carlos A. Marcano V.

picon face
Jan-Erik Soderholm wrote:

>What COM port is the Wisp628 connected to ? COM1 ?
>  
>
COM1

>What Windows version ?
>  
>
Windows XP Pro Service Pack 2

>Have you been able to get *any* communication to the Wisp628 ?
>  
>

I hooked the Wisp628 to an isolated 16F84A, just for tests. Then I downloaded the b84a-1.hex "blink-a-led" file from Wouter´s site. Then I did this:

       C:\MCHIP>xwisp.py connect

And got this:

       XWisp 1.08, command line mode
       C:\Archivos de Programa\XWisp\serialwin32.py:88: DeprecationWarning: integer arg
       ument expected, got float
         win32file.SetCommTimeouts(self.hComPort, timeouts)
       hardware: Wisp628 1.09 (fast)
       OK

As far as I can see, the xwisp is recognizing the hardware and apparently it is OK (as screened).

>When I've had a "locked" PIC (due to int-MCLR enabled), I get an
>error message saying something about the PIC not beeing found in
>the config table, or something like that.
>  
>
That´s why I tried to use a 16F84A to skip the MCLR issue but no luck at all.

Still no having luck! Thanks for the help.

Regards,

*Carlos Marcano*
-Guri, Venezuela-

2005\09\12@161117 by Jan-Erik Soderholm

face picon face
Carlos A. Marcano V. wrote :

> I hooked the Wisp628 to an isolated 16F84A, just for tests. Then I
> downloaded the b84a-1.hex "blink-a-led" file from Wouter´s
> site.

And ???
Did the LED blink ?

> That´s why I tried to use a 16F84A to skip
> the MCLR issue but no luck at all.

Are you saying that the LED did *not* blink ?

And besides, you can use *any* PIC and "skip
the MCLR issue", just do *not* enable int-MCLR !
It's up to you...

Anyway, before we know if the blink-a-led
test program *worked* on the F84A, it's hard to tell what's going on, I guess...

Jan-Erik.


2005\09\12@192829 by Carlos A. Marcano V.

picon face
Jan-Erik Soderholm wrote:

>Carlos A. Marcano V. wrote :
>
>  
>
>>I hooked the Wisp628 to an isolated 16F84A, just for tests. Then I
>>downloaded the b84a-1.hex "blink-a-led" file from Wouter´s
>>site.
>>    
>>
>
>And ???
>Did the LED blink ?
>  
>
Nop. Sorry for not saying that before.

{Quote hidden}

Yes.

>And besides, you can use *any* PIC and "skip
>the MCLR issue", just do *not* enable int-MCLR !
>It's up to you...
>
>  
>
Yes. I just wanted to use an "old known" working chip.

>Anyway, before we know if the blink-a-led
>test program *worked* on the F84A, it's hard to
>tell what's going on, I guess...
>
>  
>
Thanks for your help.

Regards,

*Carlos Marcano*
-Guri, Venezuela-

2005\09\12@230049 by PicDude

flavicon
face
Don't know/can't remember the specifics of the Wisp628, but isn't there some type of test mode where you can toggle each line (PGD, PGC, etc) to see if the programmer works and is communicating with the PC properly?

Cheers,
-Neil.


On Monday 12 September 2005 06:28 pm, Carlos A. Marcano V. scribbled:
{Quote hidden}

2005\09\12@232058 by Chen Xiao Fan

face
flavicon
face
I hope Wouter can help you on debugging the hardware.

1) Check your Wisp628 hardware

2) The problem does not occur under Linux version of xwsip2
even wrong port is specified or the chip is not there or
any other mistakes. Xwisp2 will time out and not hang there.
I tested on Ubuntu 5.04 yesterday.

3) The problem may be related to Windows XP SP2 if hardware
is not the real problem. I will try out on Windows again.

Reagrds,
Xiaofan

-----Original Message-----
From: PicDude
Sent: Tuesday, September 13, 2005 11:01 AM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] Trouble programming 16LF648A using Wisp628


Don't know/can't remember the specifics of the Wisp628, but isn't there some

type of test mode where you can toggle each line (PGD, PGC, etc) to see if
the programmer works and is communicating with the PC properly?

Cheers,
-Neil.

2005\09\12@234014 by Mark Rages

face picon face
On 9/11/05, Jan-Erik Soderholm <.....jan-erik.soderholmKILLspamspam@spam@telia.com> wrote:
{Quote hidden}

I'm a Python programmer. Maybe I can help.

The error is not a real error, just a warning.  It may be an error in
a future version of Python, which is why there is a warning.  It can
be fixed by adding a cast to int in the right place.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2005\09\13@012051 by Carlos A. Marcano V.

picon face
Updating this issue, I retried the test with another PIC16F84A and I could program it with the blink-a-led example hex from Wouter´s site using Xwisp. It looks like the other 84A was defective. I have not tested again with the 16LF648A because I have not built the dongle. I still cant read back the hex from the 84A, I keep getting weird messages. At least I can now flash and test some stuff! Thank you all for your kind help.

Regards,

*Carlos Marcano*
-Guri, Venezuela

2005\09\13@020112 by Wouter van Ooijen

face picon face
> The error is not a real error, just a warning.

The OPs problem is not thye depercation warning but what happens after
that.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\09\13@020113 by Wouter van Ooijen

face picon face
> Don't know/can't remember the specifics of the Wisp628, but
> isn't there some
> type of test mode where you can toggle each line (PGD, PGC,
> etc) to see if
> the programmer works and is communicating with the PC properly?

No, but when the PC states that it has detected a Wisp628 version
so-and-so a fair amount of communication has taken place.

As for the OPs problem: I don't recognise it. I am too busy now, but I
will conmtact him for more info in a few days.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\09\13@101029 by Xiaofan Chen

face picon face
I test the Windows versions and did not find the CTRL-C problem.

So I think the OP has a hardware problem.

Regards,
Xiaofan


Detail test on Windows XP SP2.
1) Programming an erased (blank) 12F675 with INTOSC and Internal MCLR
This should be okay since it is blank and there is no code to
interfere the PGC and PGD lines. And it is okay.

E:\Coding\XWISP2~4>xwisp2w port 2 write state.HEX
XWisp2 version 1.6.01 (Aug 14 2005, Open Watcom C 1.30)
File STATE.HEX loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Detected target: 12F675 revision 03 (ID=0FC3)
Transferring image to 12F675 via Wisp628
Transferring program memory...OK!
Transferring ID memory........OK!
Transferring data memory......OK!
Transferring fuses memory.....OK!
Write terminated successfully in 1.14 seconds
XWisp2 terminated successfully in 2.30 seconds

2) Verify first step (False alarm, PICKit 1 verified okay)
I reported this to Rob, the original author to look at the code.

E:\Coding\XWISP2~4>xwisp2w port 2 verify state.HEX
XWisp2 version 1.6.01 (Aug 14 2005, Open Watcom C 1.30)
File STATE.HEX loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Detected target: 12F675 revision 03 (ID=0FC3)
Verifying program memory......OK!
Verifying ID memory...........OK!
Verifying data memory.........OK!
Verifying fuses memory........failed at 000000, expected: '8C3F', found: '8C31'
Verify failed after 0.28 seconds, rc 21!
XWisp2 failed after 1.44 seconds, rc 21!

3) rewrite the not-blank 12F675, failed because of the existing code.

The dongle is necessary to achieve the programming but I have not
made the dongle and reluctant to do so because shorting any power
supply is not a very good idea IMHO. A better option is to control
Vdd-target at least when we have the control of Vdd-target (like
standard-alone programming). It requires some more external
circuits and some modifications of Wisp628 firmware and host
software.

E:\Coding\XWISP2170>xwisp2w port 2 write state675.HEX
xwisp2 version 1.7.00 (Sep 10 2005, Open Watcom C 1.30)
File state675.HEX loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Detected target: 12F675 revision 03 (ID=0FC3)
Transferring image to 12F675 via Wisp628
Transferring program memory...Wbus command failure
Write failed after 0.09 seconds, rc 21!
XWISP2 failed after 1.25 seconds, rc 21!

4) Try to use wrong port, Xwisp2 times out and this is expected behavior.

E:\Coding\XWISP2170>xwisp2w port 1 write state.HEX
xwisp2 version 1.7.00 (Sep 10 2005, Open Watcom C 1.30)
File state.HEX loaded and is Intel Hex format conforming
SendReceiveSlow read timeout, 0 bytes received
Failed to activate Wbus device
XWISP2 failed after 1.08 seconds, rc 23!

5) Try to programan empty target by removing the 12F675.
Xwsip2 times out and this is expected behavior.  

E:\Coding\XWISP2170>xwisp2w port 2 write state.HEX
xwisp2 version 1.7.00 (Sep 10 2005, Open Watcom C 1.30)
File state.HEX loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Target not found in configuration table
Target not auto-detected, please specify on commandline!

2005\09\13@125118 by Carlos A. Marcano V.

picon face
Xiaofan Chen escribió:

>I test the Windows versions and did not find the CTRL-C problem.
>
>So I think the OP has a hardware problem.
>  
>
Xiofan, I thought that too, but I could succesfully write a blink-a-led program (from Wouter´s site) to a 16F84A using python xwisp. I must add that every now and then the writing process fails and I get this:

C:\MCHIP>xwisp.py go prueba.hex
XWisp 1.08, command line mode
C:\Archivos de Programa\XWisp\serialwin32.py:88: DeprecationWarning: integer arg
ument expected, got float
 win32file.SetCommTimeouts(self.hComPort, timeouts)
hardware: Wisp628 1.09 (fast)
target: 16f84a, revision 00 (ID=0560)
read Code 0000Traceback (most recent call last):
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 3563, in ?
   XWisp_Main()
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 3560, in XWisp_Main
   Wisp_Line().Interpret()
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 3180, in Interpret
   self.Execute( Command )
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 3162, in Execute
   exec( 'self.CMD_' + Command.upper() + '()' )
 File "<string>", line 1, in ?
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 2595, in CMD_GO
   Regions = self.Selection )
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 2251, in Write_Verify
   Readback = self.Read( [ Region ], List = Image, Ignore = 0 )
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 2204, in Read
   Data = self.Get_Cluster( Base )
 File "C:\Archivos de Programa\XWisp\xwisp.py", line 2069, in Get_Cluster
   D = int( Response[ 0 : 2 * self.Type.Stride ], 16)
ValueError: invalid literal for int():

I also noticed that my power supply is at 5,25 V. Might this be the problem? Seems unprobable.

By the way, thanks a lot for the extensive testing procedures, I appreciate that.

Regards,
*Carlos Marcano*
-Guri, Venezuela-

2005\09\13@131817 by Wouter van Ooijen

face picon face
> I must add
> that every now and then the writing process fails and I get this:

My best guess it that you have marginal communication. Maybe a loose
pin, or the ground is not connected? Check, check, recheck your PCB,
maybe try with the Wisp628 directly in the PC (no cable).

V+ == 5.25 is definitely OK.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu





2005\09\16@014724 by Carlos A. Marcano V.

picon face
Wouter van Ooijen wrote:

>maybe try with the Wisp628 directly in the PC (no cable).
>  
>
Bingo! This was exactly the solution. I attached the Wisp628 directly to
the serial port and it worked flawlessly with a 16F84A and a 16LF648A.
It looks like I was using a defective cable, or maybe it is too long (6
Ft)?

Just a couple of questions: why when I read back any programmed hex file
to a chip I get a smaller hex file (few bytes less)? I know it is not
getting something wrong because I use this program in the chip again and
works ok.

And, for the Python gurus, I keep getting this warning when I write or
read a chip using xwisp.py:

C:\Archivos de Programa\XWisp\serialwin32.py:88: DeprecationWarning:
integer arg
ument expected, got float
 win32file.SetCommTimeouts(self.hComPort, timeouts)

Any ideas about the reason I am getting this?

Anyway, THANKS A LOT everybody for your really kind help, I trully
appreciate all the comments you made!.

Regards,

*Carlos Marcano*
-Guri, Venezuela-


2005\09\16@022839 by Wouter van Ooijen

face picon face
> >maybe try with the Wisp628 directly in the PC (no cable).

> Bingo! This was exactly the solution. I attached the Wisp628
> directly to
> the serial port and it worked flawlessly with a 16F84A and a
> 16LF648A.
> It looks like I was using a defective cable, or maybe it is
> too long (6
> Ft)?

A cable of a few *meters* should be no problem if it is reasonable
quality cable. I would still bet there is some wire not connected, or
maybe it is a crossover (0-modem) cable?

> Just a couple of questions: why when I read back any
> programmed hex file
> to a chip I get a smaller hex file (few bytes less)?

There is some freedom in how to format a hex file (number of bytes per
line). Also the readback will by default omit words that seem to be
usused ( = in the erased state, 16F code space: value 0x3FF).


> C:\Archivos de Programa\XWisp\serialwin32.py:88: DeprecationWarning:
> integer arg
> ument expected, got float
>   win32file.SetCommTimeouts(self.hComPort, timeouts)
> Any ideas about the reason I am getting this?

Because Python changed slightly after I wrote this (or rather, after I
grabbed that library).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\09\16@200320 by Xiaofan Chen

face picon face
Just want to let you know that xwips2 V1.7.01 has just been released .
It solved the "hang" problem you faced under Windows. It now
also compiles natively under Linux with GCC.

The URL of the download is http://www.robh.nl/picsoft.html.

--------------------------------------------------------------------------------------------------------------
Support software for the Wisp628 programmer under OS/2, Windows an
Linux, version 1.7.01

...
New with version 1.7.01:
* Support for Linux improved: compilable by GCC!
* Bug fixes (esp. for Windows version 1.7.00)
For details of Wisp628, Wisp and XWisp see Wouter's site.
OS/2, Windows, Linux, Freeware, released 16 September 2005.

2005\09\17@101530 by Carlos Marcano

picon face
Thanks, Xiaofan, I have taking this into account and will do some
testing on Monday.

Regards,

*Carlos Marcano*
-Guri, Venezuela-

On 16/09/05, Xiaofan Chen <xiaofancspamKILLspamgmail.com> wrote:
{Quote hidden}

> -

2005\09\17@120944 by Xiaofan Chen

face picon face
One trick to use the Wisp628 to program those with Vdd-before-Vpp
like 12F629/12F675 and maybe 16F628A/16F648A.

The blank chip does not have code inside so that the chip will not
running and no interference with PGC/PGD will happen. Therefore
erasing the chip with command like "xwisp2w port 2 erase" and
then programming the chip will be okay.

Of course this may or may not work since the erase command may
be interfered by the code running as well in theory. However this
trick works for me so far.

Wouter's dongle may be a better solution for this kind of chips. Still
I think the ultimate solution (for off-line programming) is to change
the Wisp628 design and control the Vdd-target.


Regards,
Xiaofan

2005\09\17@163112 by Wouter van Ooijen

face picon face
> Wouter's dongle may be a better solution for this kind of chips. Still
> I think the ultimate solution (for off-line programming) is to change
> the Wisp628 design and control the Vdd-target.

There is no law that the simple dongle I show on my wesbite *must* be
used. You can use the same trigger signal to switch the Vdd to the
target, but maybe you would still need to a short to remove any leftover
charge. So no change to Wisp628 is required. But If I make a new design
I would indeed provide separate signals for switch-off and for shorting.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\09\20@003813 by Carlos A. Marcano V.

picon face
Wouter van Ooijen wrote:

>A cable of a few *meters* should be no problem if it is reasonable
>quality cable. I would still bet there is some wire not connected, or
>maybe it is a crossover (0-modem) cable?
>
>  
>
Updating:
  I cutted one third of the cable (now it is about 1,4 meters long) and could easily write and read blink-a-led programs into a 16F84A and a 16LF648A (without Wouter´s dongle) flawlessly.  I used XWisp and XWisp2 (last update)  and they work perfect. Thanks to Xiaofan and Wouter for your very valuable help!

Regards,

*Carlos Marcano*
-Guri, Venezuela-

{Quote hidden}

>

2005\09\20@070326 by Xiaofan Chen

face picon face
Glad to know you make it work!

How do you deal with the 16F648A without the dongle? Take note
a blank chip will have no problem but a non-blank chip may have
problems. My tricks is to erase the chip first. Still you may want
to build the dongle.

Regards,
Xiaofan

On 9/20/05, Carlos A. Marcano V. <.....c.marcanoKILLspamspam.....gmail.com> wrote:

{Quote hidden}

> -Guri, Venezuela-

2005\09\20@125114 by Wouter van Ooijen

face picon face
> Glad to know you make it work!
>
> How do you deal with the 16F648A without the dongle? Take note
> a blank chip will have no problem but a non-blank chip may have
> problems. My tricks is to erase the chip first. Still you may want
> to build the dongle.

This might not be official behaviour, but I have never needed the dongle
with 16F628/648(A) chips. Maybe because I never use them with the
internal oscillator.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\09\20@225201 by Chen Xiao Fan

face
flavicon
face
During the test of the new Xwisp2, I also noticed that for
new device like 12F635/16F684, I never have the problem even
though the chip is configured as INTOSC and internal /MCLR.
The programming specification (DS41204E) specifically mentions
that Vdd needs to be power down before Vpp for this kind
of configuration. For 12F629/675 with the same configuration,
Wsip628 does have the problem and I need to erase them first
before programming.

Is this somewhat related to Wisp628 firmware or something else?
Maybe you can provide some insight into this.

Regards,
Xiaofan

{Original Message removed}

2005\09\21@000025 by Carlos A. Marcano V.

picon face
Xiaofan Chen wrote:

>How do you deal with the 16F648A without the dongle? Take note
>a blank chip will have no problem but a non-blank chip may have
>problems. My tricks is to erase the chip first. Still you may want
>to build the dongle.
>  
>
Well, I think that it is working because Xwisp and Xwisp2 when using the
"go" parameter they erase first, write program, check and  finally put
the target in run mode. Just my guess.

By the way, I have tested with a 16F88 also, using internal oscillator
at 8 MHz, and RA5-/MCLR-VPP pin function as /MCLR and works fine with my
Wisp628 (with the shorter cable) and using XWisp and XWisp2 softwares.

Regards,

*Carlos Marcano*
-Guri, Venezuela-



2005\09\21@015804 by Wouter van Ooijen

face picon face
> During the test of the new Xwisp2, I also noticed that for
> new device like 12F635/16F684, I never have the problem even
> though the chip is configured as INTOSC and internal /MCLR.
> The programming specification (DS41204E) specifically mentions
> that Vdd needs to be power down before Vpp for this kind
> of configuration. For 12F629/675 with the same configuration,
> Wsip628 does have the problem and I need to erase them first
> before programming.
>
> Is this somewhat related to Wisp628 firmware or something else?

Not that I know. Note that the programming specs more or less say 'if
you apply this sequence the chip will program', they don't say 'they
won't program with any other sequence'.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\09\21@040718 by Jan-Erik Soderholm

face picon face
Carlos A. Marcano V. wrote :

> Well, I think that it is working because Xwisp and Xwisp2
> when using the "go" parameter they erase first, write program,
> check and finally put the target in run mode. Just my guess.

I don't follow here...

*If* you have chip that has problem with re-programmiong if
int-MCLR is enabled (like the 12F629/675), I don't see how it
can be erased, since you have to be able to put the chip in
"programming mode" no matter what you'd like to do with it, not ?

Or is an "erase-only" operation less demanding on the access to
the chip ? Such as that you don't have to read the device ID bits
(or something) ?

> By the way, I have tested with a 16F88 also, using internal
> oscillator at 8 MHz, and RA5-/MCLR-VPP pin function as /MCLR...

If you have *external* MCLR enabled, you'll never have any
problem, AFAIK, since the Wisp628 can hold the PIC in reset
(non-running) state right up to Vpp is supplied. I guess that
that is true for any chip (?).

> and works fine with my Wisp628 (with the shorter cable)
> and using XWisp and XWisp2 softwares.

And the F88 was a less good exemple, since, AFAIK, it doesn't
show this problem (at least not when I tested reasently) no
matter how MCLR was configured (using Wouters blink-a-LED
programs, that *does* lock up a 12F chip...)

Jan-Erik.



2005\09\21@042659 by Chen Xiao Fan

face
flavicon
face
>From my experience with 12F629/675, erased it first by
ERASE command and then use the WRITE command does help
in the cases. I guess it is really less demanding.
Still it needs to read the device ID bits and then
preserve the bandgap bits (within the configuration
word) and the OSCCAL value. So I am also not so sure
why the ERASE command can do the trick in my test
cases. Without the ERASE command first, test of xwisp2
using 12F629/675 with INTOSC and internal /MCLR
will fail.

Regards,
Xiaofan

{Original Message removed}

2005\09\21@044109 by Jan-Erik Soderholm

face picon face
Chen Xiao Fan wrote :

>From my experience with 12F629/675, erased it first by
> ERASE command and then use the WRITE command does help
> in the cases. I guess it is really less demanding.
> Still it needs to read the device ID bits and then
> preserve the bandgap bits (within the configuration
> word) and the OSCCAL value. So I am also not so sure
> why the ERASE command can do the trick in my test
> cases. Without the ERASE command first, test of xwisp2
> using 12F629/675 with INTOSC and internal /MCLR
> will fail.
>
> Regards,
> Xiaofan

Interesting...

I definitly have to test this "logical dongle" myself.
It seems easier then the "physical dongle"... :-)

Best Regards,
Jan-Erik.



2005\09\21@200010 by Carlos A. Marcano V.

picon face
Chen Xiao Fan wrote:

>>From my experience with 12F629/675, erased it first by
>ERASE command and then use the WRITE command does help
>in the cases. I guess it is really less demanding.
>Still it needs to read the device ID bits and then
>preserve the bandgap bits (within the configuration
>word) and the OSCCAL value. So I am also not so sure
>why the ERASE command can do the trick in my test
>cases. Without the ERASE command first, test of xwisp2
>using 12F629/675 with INTOSC and internal /MCLR
>will fail.
>  
>
 The WRITE command for a 16F88 also works using internal osc and
internal /MCLR if you use the ERASE command first.

Regards,

*Carlos Marcano*
-Guri, Venezuela-

2005\09\22@035825 by Jan-Erik Soderholm

face picon face
Carlos A. Marcano V. wrote :

> >> From my experience with 12F629/675, erased it first by
> >> ERASE command and then use the WRITE command does help
> >> in the cases.


> The WRITE command for a 16F88 also works using internal osc and
> internal /MCLR if you use the ERASE command first.
>
> Regards,
>
> *Carlos Marcano*
> -Guri, Venezuela-

Hm, when I tested I was *not* able to lock myself out
from a F88 using the intosc/int-mclr test programs
from Wouter using a Wisp628. And I only used
the do-all command GO without any separate ERASE
command first.

I think one have to stick to the PIC model we are discussing,
since there seems to be some differences between them.

Jan-Erik.



2005\09\23@130617 by Carlos A. Marcano V.

picon face

>
>Hm, when I tested I was *not* able to lock myself out
>from a F88 using the intosc/int-mclr test programs
>from Wouter using a Wisp628. And I only used
>the do-all command GO without any separate ERASE
>command first.
>
>I think one have to stick to the PIC model we are discussing,
>since there seems to be some differences between them.
>
>Jan-Erik.
>
>  
>
So, maybe I have been lucky with the 16F88? I am waiting the arrival of
another batch of F88's to make some tests.

Regards,

*Carlos Marcano*
-Guri, Venezuela-

2005\09\23@143803 by Rob Hamerling

flavicon
face


Carlos A. Marcano V. wrote:
>
>>
>> Hm, when I tested I was *not* able to lock myself out
>> from a F88 using the intosc/int-mclr test programs
>> from Wouter using a Wisp628. And I only used
>> the do-all command GO without any separate ERASE
>> command first.
>>
>> I think one have to stick to the PIC model we are discussing,
>> since there seems to be some differences between them.
>>
>> Jan-Erik.
>>
>>  
>>
> So, maybe I have been lucky with the 16F88? I am waiting the arrival of
> another batch of F88's to make some tests.

I have a PIC program which uses all 8 PortA pins (incl /MCLR!) as
digital input and all 8 PortB pins as output, and thus needs INTOSC.
I have used it (with only small differences to disable analog functions)
with 16F88, 16F819, 16F648A and 16F628A all programmed with a Wisp628. I
did not need a 'dongle' to reprogram any of these and also no separate
erase.

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

2005\09\23@170622 by Jan-Erik Soderholm

face picon face
Rob Hamerling wrote :

> Carlos A. Marcano V. wrote:
> >
> >
> > So, maybe I have been lucky with the 16F88? I am waiting
> > the arrival of another batch of F88's to make some tests.
>
> I have a PIC program which uses all 8 PortA pins (incl /MCLR!) as
> digital input and all 8 PortB pins as output, and thus needs INTOSC.
> I have used it (with only small differences to disable analog
> functions) with 16F88, 16F819, 16F648A and 16F628A all
> programmed with a Wisp628. I did not need a 'dongle' to
> reprogram any of these and also no separate erase.
>
> Regards, Rob.

And to add to that, the *only* devices that I have had to use
the dongle with are the 12F629/675. I have had the same
experience with the F88 as Rob (re-programmed OK using
both intosc and int-mclr without the dongle).

Regards,
Jan-Erik.



2005\09\23@225756 by Xiaofan Chen

face picon face
That is good news. Only 12F629 and 12F675 cause problem. I've only played
with 12F629/675/635 and 16F684 and I find there is no problem with 12F635
and 16F684. You must have played with more chips than I.

Even better news is that the "software dongle" seems to work (erase first before
write). I am now testing Rob's latest Xwisp2 1.7.2 version and the "go"
command is working without the hardware dongle. If more people can
confirm that the "software dongle" is working for 12F629/12F675, there is
no more need for hardware dongle. We just beed to use the most
often used "go" command now.

Maybe you (Jan-Eric) can try out this as well to see if this is the case for
12F629/675 on Windows. I will test it later as well on Windows.

Regards,
Xiaofan

***********Test on Linux for xwsip2 1.7.2 test 2 version*****************
1) using write command will sometimes fail because of the INTOSC and internal
/MCLR.

mcuee@ubuntu:~/Desktop/build/xwisp2/xwisp2172$ ./xwisp2u port
/dev/ttyS1 write state6752.hex
xwisp2 version 1.7.02 for Linux (Sep 22 2005, Open Watcom C 1.30)
File state6752.hex loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Detected target: 12F675 revision 03 (ID=0FC3)
Transferring image to 12F675 via Wisp628
Transferring program memory...Wbus command failure
Write failed after 0.14 seconds, rc 21!
xwisp2 failed after 1.13 seconds, rc 21!

2) Erase and then write will work from my testing
mcuee@ubuntu:~/Desktop/build/xwisp2/xwisp2172$ ./xwisp2u port /dev/ttyS1 erase
xwisp2 version 1.7.02 for Linux (Sep 22 2005, Open Watcom C 1.30)
Programmer Wisp628, firmware version 1.09
Detected target: 12F675 revision 03 (ID=0FC3)
Target erased
xwisp2 terminated successfully in 1.33 seconds
mcuee@ubuntu:~/Desktop/build/xwisp2/xwisp2172$ ./xwisp2u port
/dev/ttyS1 write state6752.hex
xwisp2 version 1.7.02 for Linux (Sep 22 2005, Open Watcom C 1.30)
File state6752.hex loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Detected target: 12F675 revision 03 (ID=0FC3)
Transferring image to 12F675 via Wisp628
Transferring program memory...OK!
Transferring ID memory........OK!
Transferring data memory......OK!
Transferring fuses memory.....OK!
Write terminated successfully in 1.27 seconds
xwisp2 terminated successfully in 2.25 seconds

3) "go" command is doing erase first for this version. I have not tested
the old versions

mcuee@ubuntu:~/Desktop/build/xwisp2/xwisp2172$ ./xwisp2u port
/dev/ttyS1 go state6752.hex
xwisp2 version 1.7.02 for Linux (Sep 22 2005, Open Watcom C 1.30)
File state6752.hex loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Detected target: 12F675 revision 03 (ID=0FC3)
Target erased
Transferring image to 12F675 via Wisp628
Transferring program memory...OK!
Verifying program memory......OK!
Transferring ID memory........OK!
Verifying ID memory...........OK!
Transferring data memory......OK!
Verifying data memory.........OK!
Transferring fuses memory.....OK!
Verifying fuses memory........OK!
Write-Verify terminated successfully in 1.62 seconds
Putting target in run mode


On 9/24/05, Jan-Erik Soderholm <EraseMEjan-erik.soderholmspam_OUTspamTakeThisOuTtelia.com> wrote:
>
> And to add to that, the *only* devices that I have had to use
> the dongle with are the 12F629/675. I have had the same
> experience with the F88 as Rob (re-programmed OK using
> both intosc and int-mclr without the dongle).
>
> Regards,
> Jan-Erik.
>

2005\09\27@182352 by Jan-Erik Soderholm

face picon face
Xiaofan Chen wrote :

> Even better news is that the "software dongle" seems to work
> (erase first before write). I am now testing Rob's latest Xwisp2
> 1.7.2 version and the "go" command is working without the
> hardware dongle. If more people can confirm that the
> "software dongle" is working for  12F629/12F675, there is
> no more need for hardware dongle. We just beed to use the
> most often used "go" command now.

Hi.

I've *not* been able to reproduce this on WinXP, Wisp628 1.09
and XWisp2 1.7.02 on 12F629 and 675 (tried both).

I've tried a lot of combinations of erase, write, target and go...

I need to connect Wouter's dongle to be able to "lock up"
the 12F's again after flashing b675i-2.hex from Wouters
blink-a-led page. That hex uses both intosc and int-mclr.

Regards,
Jan-Erik.



2005\09\27@202303 by Chen Xiao Fan

face
flavicon
face
I will try with Wouter's hex file on Windows XP as well
as Linux to see if it is problematic and report my result
here. My test hex file uses all the 8-pins of the
12F629/675 and internal OSC and internal MCLR. Looks like
the trick is not universal and the dongle is still necessary.

Anyway I hope Wisp648 will be USB based and will have the
control over Vdd-traget. ;-)

Regards,
Xiaofan

{Original Message removed}

2005\09\27@204703 by John Nall

picon face
Chen Xiao Fan wrote:

>> Anyway I hope Wisp648 will be USB based and will have the
>control over Vdd-traget. ;-)
>  
>
I hope just the opposite.  I have had nothing but trouble with using the
ICD2 in the USB mode, and finally gave up in disgust.  Let me put it
very plainly -- USB sucks.  So please keep the Wispxxx serial-port
based.  Perhaps one of  these days USB will be straightened out, but in
the meantime I prefer stuff  that works consistently, rather than
according to the phase of  the moon.

John

2005\09\27@210334 by Chen Xiao Fan

face
flavicon
face
It is not that "USB sucks". It is "the driver sucks".

Lot of the people have to use USB dongle to work
with serial based Wisp628A and EasyProg. So I think
it is good to build the USB dongle insider Wisp648A
and EasyPorgUSB (?).

Let's wait and see if Wisp648A will be serial based or
USB based.

Regards,
Xiaofan

{Original Message removed}

2005\09\28@014954 by Wouter van Ooijen

face picon face
> Let's wait and see if Wisp648A will be serial based or
> USB based.

The plan is to make Wisp648 a pic/firmware update for the Wisp628 PCB,
and Wisp2550 similar but using the PICs built-in USB interface.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\09\28@031958 by Chen Xiao Fan

face
flavicon
face
I am quite curious about the Wip648A and Wisp2550.
Which PICs will the Wisp648A firmware support?
More 18Fs like 18F USB parts? 16F91x LCD parts?
Even dsPICs? How about Wisp2550? Will it be similar
to PICKit 2?

Regards,
Xiaofan

-----Original Message-----
From: Wouter van Ooijen
Sent: Wednesday, September 28, 2005 1:50 PM
To: 'Microcontroller discussion list - Public.'
Subject: RE: [PIC] Trouble programming 16LF648A using Wisp628

> Let's wait and see if Wisp648A will be serial based or
> USB based.

The plan is to make Wisp648 a pic/firmware update for the Wisp628 PCB,
and Wisp2550 similar but using the PICs built-in USB interface.

Wouter van Ooijen

2005\09\28@094401 by Xiaofan Chen

face picon face
Hi Jan_Eric,

You are absolutely correct. The "software dongle" does not work
on my Windows XP box as well. I only tried 12F675 and
xwisp2 1.7.2. After successfully writing the blank chip, all
subsequent erase or go command failed.

Therefore the real dongle is still needed for 12F629/12F675.

Regards,
Xiaofan

1) Tried to erase: not really erased
E:\Coding\XWISP2172>xwisp2w port 2 erase
xwisp2 version 1.7.02 for Windows (Sep 25 2005, Open Watcom C 1.30)
Programmer Wisp628, firmware version 1.09
Detected target: 12F675 revision 03 (ID=0FC3)
Target erased
xwisp2 terminated successfully in 1.51 seconds

E:\Coding\XWISP2172>xwisp2w port 2 erase
xwisp2 version 1.7.02 for Windows (Sep 25 2005, Open Watcom C 1.30)
Programmer Wisp628, firmware version 1.09
Target not found in configuration table
Target not auto-detected, please specify on commandline!
xwisp2 failed after 1.06 seconds, rc 23!

2) Tried to program with "go" command --> failed
E:\Coding\XWISP2172>xwisp2w port 2 go b675i-1.hex
xwisp2 version 1.7.02 for Windows (Sep 25 2005, Open Watcom C 1.30)
File b675i-1.hex loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Target not found in configuration table
Target not auto-detected, please specify on commandline!
xwisp2 failed after 1.06 seconds, rc 23!

E:\Coding\XWISP2172>xwisp2w port 2 go b675i-1.hex
xwisp2 version 1.7.02 for Windows (Sep 25 2005, Open Watcom C 1.30)
File b675i-1.hex loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Detected target: 12F675 revision 03 (ID=0FC3)
Target erased
Transferring image to 12F675 via Wisp628
Transferring program memory...Wbus command failure
Write-Verify failed after 0.08 seconds, rc 21!
xwisp2 failed after 1.73 seconds, rc 21!


On 9/28/05, Jan-Erik Soderholm <jan-erik.soderholmspamspam_OUTtelia.com> wrote:
{Quote hidden}

> -

2005\09\28@162308 by Stan Rife

flavicon
face
Wouter,
       Wonder when Wisp648 might be available, and what the differences are
going to be.

Stan Rife
W5EWA
Houston, TX
K2 S/N 4216


{Original Message removed}

2005\09\28@173907 by Wouter van Ooijen

face picon face
>        Wonder when Wisp648 might be available, and what the
> differences are going to be.

sorry, my crystal ball is too misty too see...

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...