PDA

View Full Version : 18F1320 ... Strange Memory



Acetronics2
- 4th April 2006, 15:41
Hi all,

I wrote a nice piece of code ( 3200 hex lines ...) for a 16F648 an a 16F88 : Everything works OK ! ... thank you.

BUUUUUT, Trying to use it aboard a 18F1320 ... things become quite funny :

Let's see:

Program runs ... but...

I have to memorize in the EEPROM 8 values "in a row" ( from 1 to 8 ) and then Three others, one by one, at locations 10,11, and 12.

The first 8 are well Stored ... but the 3 others never want to be stored !!!

Somewhere else, after that, I can modify values 1 and 2 ...

They are properly modified and stored !!!!

So, shortly ... my 18F1320 seems to have only 8 addressable EEPROM registers.
I tried to push the 3 lonesome values to $11, 12 and 13 ... no more result.

Anyone understanding that ???

( Setting WREN to 1 doesn't modify anything ... )

Alain

Acetronics2
- 5th April 2006, 14:47
Hi, Mel

No idea ???

( source has of course being written in PbP ... ~ 700 lines )

Alain

Luciano
- 5th April 2006, 15:53
Hi,

Disable interrupts when you write the internal EEPROM.
(From the datasheet).

Can you write a small PicBasic program that only
write and read the byte at location 10?

Can you write location 10 with a chip programmer and
then read the same location with PicBasic?

Can you write a small assembly program that only
write and read the byte at location 10?
(See datasheet).

Best regards,

Luciano

Melanie
- 5th April 2006, 16:09
Kinda difficult to comment without seeing the code that reads and writes to the EEPROM... really as Luciano states, create some simple code to write to EEPROM, then read it back and verify.

What I normally do, is also read the EEPROM back in my Programmer (always assumining your has that capability) and doubly confirm what I've written is actually stored there. That way you can concentrate on debugging the READ or the WRITE part of your code.

Of course you do have the latest PBP and MPLAB that has eliminated the internal EEPROM anomalies of the earlier versions?

sougata
- 5th April 2006, 16:36
Hi,

I once found on a PIC18F452 that if I codeprotect the first 512 bytes (boot) of the chip then my eeprom storage would no longer work. Leaving it out and protecting the other pages did the trick.

Acetronics2
- 5th April 2006, 16:39
Hi, Mel and Luciano

PbP is 2.46 "patched" release, and MPASM v 5.02 ... and ... no chance to use PM here !!! ( 18F1320 not supported ... it says)

If you want, I send you the code ... no secrets there !!!

There are no interrupts in this program ... I ever try not to use ... to avoid input parasitic signals difficulties ...

I've read memory w/ my picstart ... that's how I found what was happening.

The only thing I didn't try was to write into the memory not only 8 but, say, 20 values following each others...

I changed the values types ... no more luck !!!

And do not forget memory use is OK with 16F devices ...

Thanks for your Help

Alain

Acetronics2
- 5th April 2006, 18:05
Last news :

I added a value at position 9 (0 ) and copied the "writes" from location 1 to 9 to 21 to 29 ...

result : all values Written ... except value at loc.2 that has been overwritten by "FF" .... my three lonesome further values always aren't written.

may be there are overwritten too ... i'll never know.

one sure thing ... there's a writing problem !!!

Alain

Hi, SOUGATA

All writing protections have been removed ... I have to program in two times : at first config , and then program. default configs locks the programming !!!

Luciano
- 5th April 2006, 18:07
WRITE 2,NeutreC.lowbyte
WRITE 1,NeutreC.highbyte
WRITE 4,GaucheC.lowbyte
WRITE 3,GaucheC.highbyte
WRITE 6,DroiteC.lowbyte
WRITE 5,DroiteC.highbyte
WRITE 7,Invert <<<<<<<<< Invert is declared as BIT
WRITE 8,Side <<<<<<<<< Side is declared as BIT


I don't use PicBasic.

Will "WRITE" support the BIT data type?
Try to declare the variables Invert and Side as BYTE.

Best regards,

Luciano

Acetronics2
- 5th April 2006, 18:12
Hi, Luciano

Bit is well written in the EEPROM ...

Alain

inteco
- 5th April 2006, 18:29
I notice some problem with the programmer software too
in writing the EEPROM data for the memory location.
But seems melabs has corrected on their newer ver 3.31.
I can tell from running debugging while reading the EEPROM
data via rs232.

Acetronics2
- 6th April 2006, 13:19
Hi,

I've tried to see closer what's happening, so :

Values are Written 3 times, at locations 1-12 , then 21-32, then 41-52 ...

Memory is filled w/ zeros at programming time

Then run ...

Attached is the EEPROM Dump ...

Locations $0A, $0B and $0C are a bit surprising ... Values should have been $7F ... as loc. $1E, $1F, $20 and $32, $33, $ 34.

a bug somewhere ???

Alain

Luciano
- 6th April 2006, 13:26
Alain,

Can you try declare the variables Invert and Side as BYTE?
(Just a quick test).

Best regards,

Luciano

Acetronics2
- 6th April 2006, 13:45
Sorry Luciano

Same result ...

Alain

Acetronics2
- 6th April 2006, 14:22
Hi all,

I finally got it ...

But I had to memorize 2 times the values ... and read the second writings.

So, I think ...

one lonely WRITE command writes the value FF instead of what you want !!!

I stop here ...

Working program attached ...

Alain

PS:
for curious guys ... that is just a simple R/C gadget to use two servos in parallell ... Neutral, 2 1/2 travels, finely adjustable, plus invertible rotation for servo n°2 ...
There's also a fail-safe ... servos are driven to their neutral ( recorded ...) position, if signal lost.
Plus visual programming help w/ three LEDS ...
Yessss ....

Melanie
- 6th April 2006, 15:02
No, you have a problem... WRITING the value TWICE is not correct.

You DO need up-to-date PBP and MPLAB (MPASM) as there was an EEPROM issue going back to v2.45 I think. Half the problem was Microchips Assembler too. Latest versions of everything work as expected in this department. Unfortunately I don't have that particular PIC to confirm your results.

http://www.picbasic.co.uk/forum/showthread.php?t=547

Acetronics2
- 6th April 2006, 15:07
My PbP and MPASM are the last versions : I verified it this morning ... and re-loaded PbP and its patch

PbP 2.46 Patched and MPASM 5.02 ...

Sorry, Mel ...

Melanie
- 6th April 2006, 15:11
You have CONFIRMED you are invoking the latest PBP and MPASM and not an old installed version by mistake or error in path statements?

Acetronics2
- 6th April 2006, 15:13
YES, I do confirm ... old versions are always thrown to the trash box ...

PbP used version seen in the MPLAB / Output/ Build window too ...

Alain

Melanie
- 6th April 2006, 15:20
Just because I'm a nice girl, I've ordered one... hopefully, I'll have a 18F1320-I/P tomorrow...

Acetronics2
- 6th April 2006, 15:30
Hi, Mel

And you know why I tried to use the 18F1320 ???

Just because 16F648 and 16F88 are not so easy to find by one part ...

This gadget will be published this summer inside THE only FREE model Webzine ( http://aeronews.free.fr/index.html ) ... no money to earn for me .. or so little !!!

.... Funny, I got This from Jeff Schmoyer ...

" If it works well with the 16F88, you might want to stick
to that device. You might also want to compare the
erratas from Microchip on the devices you are using. "

What to think of that ???

Thanks for your Help,

Alain

mister_e
- 6th April 2006, 15:36
That's maybe just another Microchip way of reinvent the wheel.... This may be another specific device who need another special method to write to eeprom and plah plah... BUT how about if you use the assembler method stated in the datasheet AND/OR errata to write to the eeprom?

Could also be another MPASM problem... wich is still possible. Did you contact Microchip tech-Support http://support.microchip.com Usually they answer within 24 hours

Sorry Alain i don't have any handy 18F1320 to test it. I'll order some sample for myself too to play with them when health permit to stay awake more than 1 hour steady.

Melanie
- 6th April 2006, 15:41
I'm thinking that swapping a $2 part for the most expensive item on the menu at Le Cinq next time I'm in Paris is a good investment *smiles*

mister_e
- 6th April 2006, 15:47
Probably the only thing you'll have for your 2$ is a smile... and again LOL!

Luciano
- 6th April 2006, 17:24
Alain,

What is the manufacturing date code of your 18F1320?

Luciano


Picture from the internet:
http://img10.picsplace.to/2/pic18f1320_1.jpg (http://picsplace.to/)

Acetronics2
- 6th April 2006, 18:05
Hi,Luciano

I have 05250SE as a code.

I bought them at the end of last year ( 2005 ) from FARNELL.

I've seen the errata giving an increasing EEPROM Writing time from 4 to 5.5 ms ...

may be, MPLAB didn't follow ...

something strange is I have to program it in 4 times ( ! ) to get 100% success

1) Erase all
2) Config words only( Ok only at second pass ...)
3) Program only
4) EEPROM only

setting to "Auto select" fails at each trail ... " Erase all at first" too

Alain

mister_e
- 6th April 2006, 18:32
Maybe MPASM don't follow or just consider the newer device... I'll not be surprise if so...

Let's see what Melanie will discover with her brand new version.

Dave
- 6th April 2006, 19:48
Acetronics, Last year I worked on a project for almost 4 months trying to get an 18F1320 to operate @ 40 Mhz. and then @ 20 Mhz. with eratic results. After looking at the data sheet I decided to use the 16F88 and have never gone back to the 18F1320. The errata sheets tell all. I ordered parts from DigiKey and they said that they had the latest hardware on hand but after receiving 50 parts of an old revision I gave up ordering from them. I was on the MicroChip forum for about 2 months and found out that they wern't very stable as far as the PLL goes and very sensitive to power supply variations. Like I said after looking at the data sheets of the 2 I decided to go with the 16F88 and haven't looked back yet. LOL

Dave Purola,
N8NTA

Luciano
- 7th April 2006, 14:33
Alain,

The oscillator speed of your PIC is 20MHz.

Can you try to change "DEFINE OSC 20" in "DEFINE OSC 25" and flash
the PIC running at 20 MHz with this code? If you try that you will
probably increase the EEPROM writing time and see if ONE write is
enough. This is just a test.

Best regards,

Luciano

EDIT:
Are you absolutely sure that the oscillator speed is correct?

-

Acetronics2
- 7th April 2006, 14:40
BUT how about if you use the assembler method stated in the datasheet AND/OR errata to write to the eeprom?



Hi, Steve

I looked at the 2 methods µchips proposes ( Sleep/ Wake on Interrupt or WR polling ) ...
In fact the two methods are based on the WR bit clearing ... so why would one be better than the other !!!

Writing time is given by the hardware ... no way to increase it !!!

PbP uses the polling method, and I don't see anything hazadous in that the GIE bit is firmly set to 0 ... and I never set it to 1 in that program.

Hope you'll soon be on your legs ...

Amitiés from the " Maudit Français"

Alain

Acetronics2
- 7th April 2006, 15:33
Alain,

The oscillator speed of your PIC is 20MHz.

Can you try to change "DEFINE OSC 20" in "DEFINE OSC 25" and flash
the PIC running at 20 MHz with this code? If you try that you will
probably increase the EEPROM writing time and see if ONE write is
enough. This is just a test.

Best regards,

Luciano

EDIT:
Are you absolutely sure that the oscillator speed is correct?

-

Hi,Luciano

Sorry, but that won't give anything ... as the EEPROM writing time is controlled by the PIC Hardware ...

For the Osc speed, it's correct : 1.52 ms input signals give ( 279 + 7H ) Hex.

( EEPROM addresses are: 01 high byte, 02 low byte, and 30 Offset )

Thanks for the idea ...

Alain

Luciano
- 7th April 2006, 17:36
Alain,

I understand that at completion of the write cycle, the WR
bit is cleared in hardware and the EEPROM Interrupt Flag bit
(EEIF) is set. The user may either enable this interrupt
or poll the WR bit. There is also a third barbarous method which
is just wait 10 ms.

In your post you say that PbP uses the polling method. This
should be ok if the microcontroller hardware has no bug.

Can you put a "PAUSE 10" after each WRITE in your code?
(10 ms pause).

Best regards,

Luciano

Acetronics2
- 7th April 2006, 18:15
Sorry one more time, Luciano ... the problem only occurs with a single writing !!!

a Pause won't change anything ... and won't change the EEPROM writing time.

Alain

Luciano
- 8th April 2006, 13:29
Alain,

From the revision history of the 3 documents....

- PIC18F1220/1320 Rev. B1 Silicon/Data Sheet Errata
- PIC18F1220/1320 Rev. B4 Silicon/Data Sheet Errata
- PIC18F1220/1320 Rev. D0 Silicon/Data Sheet Errata

... I can see that the silicon B1 and B4 have suffered from
silicon EEPROM issues. For the silicon D0 there is only a
change in the Data Sheet. No silicon EEPROM issues. (For now).

Your project is going to be published in a magazine.
Will your readers have always the right silicon version of
the 18F1320, the right MPASM version and the right PBP version?
Are you going to publish three different software versions
with the workarounds suggested by Microchip? This will be
difficult to manage for your readers.

From your replies in this thread I only see your determination
to make your project work with this chip, regardless if the chip
has a problem or not. I am surprised when you say that the problem
only occurs with single byte writing. As you already know, if
you look at your EEPROM dump file you will see that the same 11
values are written 3 times at different addresses. This is one
problem. The "FF" you get when your PBP program writes only one
byte is one more problem. (When PBP WRITE is called only once).
Note that this byte is also written 3 times, first time "FF" and
then twice again with the correct value "7F" at different addresses.
The "FF" is probably an incomplete write. (EEPROM auto clear
before write).Is the EEPROM dump file correct? Can you confirm it
by reading the 256 bytes with a test program? How many chips did
you try? There are many questions still open. If you can only program
with PBP, then a pause of 10 ms after each of the 11 WRITE could maybe
show something new in the dump file. If you don't have time to write
some test code then just use a 16F648 or a 16F88 for your publication
in the internet magazine.

Best regards,

Luciano


===============================================
===============================================
===============================================

PIC18F1220/1320 Rev. B1 Silicon/Data Sheet Errata
http://ww1.microchip.com/downloads/en/DeviceDoc/80160f.pdf

DOCUMENT REVISION HISTORY

Rev A Document (06/2003)
First revision of this document, silicon issues 1 (Data
EEPROM), 2 (Data EEPROM), 3 (Core), 4 (INTOSC),
5 (Internal Oscillator Block), 6 (Internal Oscillator
Block), 7 (Electrical Specifications), 8 (EAUSART),
9 (EAUSART) and 10 (EAUSART) and Data Sheet
Clarification issues 1 (Internal RC Accuracy) and 2 (DC
Characteristics Table).

Rev B Document (10/2003)
Added silicon issue 1 (Core).

Rev C Document (12/2003)
Removed silicon issue 2 (Data EEPROM). Changed
silicon issue 8, 9 and 10 (was issue 9, 10 and 11) from
EAUSART to USART. Added silicon issue 11 (Data
EEPROM).

Rev D Document (05/2005)
Removed silicon issue 7 (Electrical Specifications),
added silicon issue 11 (Reset), changed previous label
of USART to EUSART in silicon issues 7, 8 and 9 (to be
consistent with the data sheet) and added Data Sheet
Clarification issue 1 (CCP).

Rev E Document (08/2005)
Added Data Sheet Clarification issue 2 (Data EEPROM
Memory).

Rev F Document (03/2006)
Corrected part number revision IDs in the table on page
one.

===============================================
===============================================
===============================================

PIC18F1220/1320 Rev. B4 Silicon/Data Sheet Errata
http://ww1.microchip.com/downloads/en/DeviceDoc/80175e.pdf


DOCUMENT REVISION HISTORY

Rev A Document (12/2003)
First revision of this document, silicon issues 1 (Core),
2 (EUSART) and 3 (Data EEPROM) and Data Sheet
Clarification issues 1 (Internal RC Accuracy) and 2 (DC
Characteristics Table).

Rev B Document (2/2004)
Added silicon issue 4 (EUSART). Added Data Sheet
Clarification issue 3 (Timer1 Oscillator and In-Circuit
Serial Programming).

Rev C Document (4/2004)
Added Data Sheet Clarification issues 4 (DC
Characteristics) and 5 (LVD Characteristics).

Rev D Document (05/2005)
Added silicon issue 5 (Reset) and removed all Data
Sheet Clarification issues with the exception of former
issue 3 (Timer1 Oscillator and In-Circuit Serial
Programming™), now numbered issue 1 and added
issue 2 (CCP).

Rev E Document (08/2005)
Removed Data Sheet Clarification issue 1 and added
issue 2 (Data EEPROM Memory).

===============================================
===============================================
===============================================

PIC18F1220/1320 Rev. D0 Silicon/Data Sheet Errata
http://ww1.microchip.com/downloads/en/DeviceDoc/80244b.pdf


DOCUMENT REVISION HISTORY

Rev A Document (08/2005)
First revision of this document. Includes silicon issues 1
(Core), 2 (EUSART), 3 (Reset) and 4 (Oscillator
(INTOSC Source)), and Data Sheet Clarification issues
1 (Timer3 (Special Event Trigger)) and 2 (Data
EEPROM).

Rev B Document (03/2006)
Removed previous silicon issue 4 and added new silicon
issues 4 (Oscillator/INTOSC) and 5 (Oscillator/INTRC).
Data Sheet Clarification issue 1 (CCP) clarified as
Timer3/Special Event Trigger.

================================================== ============
================================================== ============
================================================== ============

Melanie
- 8th April 2006, 13:29
I've studied two chips...

Both have a Batch Code of 05250SE and a Silicon Revision of DEVID2=07h DEVID1=C4h (located at 3FFFFEh and 3FFFFFh respectively).

This is my Test Code, run on internal Oscillator at 4 and then at 8MHz... compiled with PBP2.46 with patches and MPASM 5.01.



'
' EEPROM Test Program for PIC18F1320
' ----------------------------------
' Melanie
' 07/04/2006
' ----------

'
' PIC Defines
' -----------
@ __CONFIG _CONFIG1H, _IESO_OFF_1H & _FSCM_OFF_1H & _INTIO1_OSC_1H
@ __CONFIG _CONFIG2L, _PWRT_ON_2L & _BOR_OFF_2L & _BORV_20_2L
@ __CONFIG _CONFIG2H, _WDT_ON_2H & _WDTPS_32K_2H
@ __CONFIG _CONFIG3H, _MCLRE_OFF_3H
@ __CONFIG _CONFIG4L, _DEBUG_OFF_4L & _LVP_OFF_4L & _STVR_ON_4L

@ __CONFIG _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L
@ __CONFIG _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H
@ __CONFIG _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L
@ __CONFIG _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H
@ __CONFIG _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L
@ __CONFIG _CONFIG7H, _EBTRB_OFF_7H

'
' Hardware Defines
' ================
'
' PIC Speed
' ---------
Define OSC 8

'
' LCD Display
' -----------
Define LCD_DREG PORTB ' Port for LCD Data
Define LCD_DBIT 4 ' Use upper 4 bits of Port
Define LCD_RSREG PORTB ' Port for RegisterSelect (RS) bit
Define LCD_RSBIT 3 ' Port Pin for RS bit
Define LCD_EREG PORTB ' Port for Enable (E) bit
Define LCD_EBIT 2 ' Port Pin for E bit
Define LCB_BITS 4 ' Using 4-bit bus
Define LCD_LINES 2 ' Using 2 line Display
Define LCD_COMMANDUS 2000 ' Command Delay (uS)
Define LCD_DATAUS 50 ' Data Delay (uS)
'
' Other Ports
' -----------
LED var PortB.0

'
' Software Defines
' ----------------
CounterA var BYTE ' Just a Counter
DataA var BYTE ' Byte Variable for Data
DataB var BYTE
EEPROMError var BIT ' Error Flag

'
' EEPROM Presets
' --------------
Data @0,"This is a Test String that should be overwritten"
Data "by the Write to EEPROM routine"

'
' Start Program Here
' ==================

'
' Initalise PIC
' -------------
OSCCON=%01110010
ADCON1=%01111111
TRISB=%00000000
Low LED
Pause 2000
High LED

'
' Write to EEPROM
' ---------------
LCDOut $FE,1,"Writing EEPROM",$FE,$C0,"A="
For CounterA=0 to 255
DataA=255-CounterA
LCDOut $FE,$C2,#CounterA
Write CounterA,DataA
Next CounterA
LCDOut $FE,1,"Write Complete"
Pause 2000

'
' Read & Verify EEPROM
' --------------------
EEPROMError=0
LCDOut $FE,1,"Verifying EEPROM",$FE,$C0,"A="
For CounterA=0 to 255
LCDOut $FE,$C2,#CounterA
Read CounterA,DataA
DataB=255-CounterA
If DataA<>DataB then
LCDOut $FE,$C6,"E=",HEX2 DataB
LCDOut $FE,$CB,"R=",HEX2 DataA
EEPROMError=1
Pause 2000
LCDOut $FE,$C6,REP 32\11
endif
Next CounterA
LCDOut $FE,1,"Write Complete"

'
' Result
' ------
LCDOut $FE,$C0,"Chip Test "
If EEPROMError=0 then
LCDOut "Pass"
else
LCDOut "Fail"
endif

EndLoop:
Pause 500
Toggle LED
Goto EndLoop

end


And the result?

One chip fails miserably, and the other works perfectly. The appended picture shows the good PIC passing at 8MHz... frequency counter is measuring Internal Oscillator OUT on RA6 which is fosc/4.

The PIC that failed did NOT write to EEPROM... it's previous contents were untouched, the Read section reported $FF from every memory Location (that had not previously been preset by a DATA statement). I have not had time to impliment the ERRATA (Section 10 Page 3) suggestions from Microchip and verify if the dud PIC works with one or both of them.

Alain, email or message me your address off-list and I'll send you the working PIC - you can then see if your program works on that.

Acetronics2
- 8th April 2006, 14:49
Hi, Mel

What a nice Job .... "La Claaaasse" as we say here !!!

just one comment: I noticed here memory locations were ERASED to FF instead of Written to expected values ...

For my tests I programmed all EEPROM to zero .... and I read some "FF" 's

see attachment for that.

You're right ... result is the same. In this case not exactly !!! I did a little mistake Testing at the beginning unwritten Offsets as Words ( Declared as bytes ... no, not on the head, please ...).

So, without this little mistake, I'd never had found this BUG ... my program would simply have locked at 2nd power-up !!!


My Address is not a secret ...

xxx

FRANCE

Close to DIEPPE or Le Tréport along the Channel, for your next visit to France ( at home coffee is free ...)

Thanks one more time

Alain


Hi, Luciano

Nice result from you too ... Microchip search engine can be upgraded, I didn't find anything in the knowledge base !!!

This device is intended to be used on big scale flying models ...

so, security first !!! ... no 18F1320 reference or soft will be published then ( I saw some, last year on another project ... gasp !!! ).

I'll do a trail with BOR enabled to the lowest possible voltage to confirm ... as, to this day, std. 4.3v BOR enabled was equal to plane death !!!

I'll wait for BUGS to be solved ... to use a 18F1320.

As Mel has written, There's no "common people" way of identifying good and bad parts ... my Picstart didn't allow me to read DEVIDs ... ( restricted area !!! ) .

Thanks a lot for your help ( in general on this forum ) and here for me.

Alain

Melanie
- 8th April 2006, 15:10
Btw... I checked EEPROM WRITE on the good PIC all the way down to 2.15v Vdd and it works fine. It's on it's way to you first thing Monday morning.

When you get it, send back one of your duds to me... they're more interesting to play with than working ones.

Acetronics2
- 8th April 2006, 15:25
Of course, the red servo is the master, and the black one, the ... slave.

French humour must go on !!!

Mel, I have a piece w/ pin B.0 "grilled" ( but processor running ) ... do you want it too ??? It has been socketed Upside Down ... during the 122 th trail !!!

Alain

Acetronics2
- 8th April 2006, 15:37
Hi, Luciano

I've set BOR to ON ... then writing is correct !!!

You're the winner of the day ...

Luciano
- 8th April 2006, 16:30
Alain,

Your chip is a D0 Silicon version. (Same date as Melanie).

If I am the winner of the day, Microchip is the loser of the day because
they will have to add this workaround also in the Errata Silicon D0 document.

Glad to hear that things are moving forward!

Best regards,

Luciano

Acetronics2
- 8th April 2006, 17:01
It was rather difficult to program the chip ... W/ my Picstart

I cleared my program from " double writings " ...

Now, it's become impossible to re-program the chip ...

only config can be entered at the THIRD try ...

EEPROM at the first ...

All the program memory is read as FF ...

ERROR ...ERROR ... ERROR ....

Trash BOX !!!

Alain

Luciano
- 8th April 2006, 17:27
Hi,

See this link:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010069&part=UK003010


The PICSTART® Plus Flash Upgrade Module (PUM) is a PCB that contains
a PIC18F6720 device that has been programmed with the firmware needed
to provide support for a specific set of devices in the MPLAB® IDE.

My comment:
The PIC18F6720 device is the "workarounds" container.

Luciano

Dave
- 9th April 2006, 02:23
Luciano, Workarounds container? Whats that all about? I have used my PUM for about a year or so with no dificulty. I have put it aside however because Microchip doesn't support all of there processors on it. I now use the ICD2 which supports all of there processors and I probably will never go back.

Dave Purola,
N8NTA

mister_e
- 9th April 2006, 09:54
ICD-2 is a great programmer, far better than PICSTART for less money
PICSTART is a fair to good programmer. Got once a problem with the PUM. ICSP support is fair to good... BAD in few ocvcasion too.

The best investement i did is my BK Precision 844A (a relabeled of XYZ Elnec programmer) That's an universal programmer support is lifetime Free of charge and works like a charm ICSP or not. So last week i trash my Picstart and ICD-2, wich i consider now as a pure waste of money AND Even if an ICD could, in rare occasion, handy. There's so many other method to do serious DEBUG instead of using ICD.

Sure BK-844A is much expensive but do more than only PIC

Luciano
- 9th April 2006, 09:55
Hi,

==========================================
README Files for MPLAB IDE v7.31
http://ww1.microchip.com/downloads/en/DeviceDoc/ReadmeMP731.zip

The above link is from this page:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469

UNZIP the file and open the file "Readme for PICSTART Plus.htm"

Release Notes for PICSTART Plus® Device Programmer

MPLAB® IDE v7.31
Software DLL Version v4.30.02
Operating System Versions v4.40.01 (pspls44001.hex)
February 8, 2006

In the device support List you will see:

PIC18F1320#

Where the # = Some revisions of these parts fail to program.

==========================================

See also this thread:

http://forum.microchip.com/tm.aspx?m=151295

==========================================

Best regards,

Luciano