Maker Pro
Maker Pro

ATMEL 89C51RD2 programming problem

T

ted

Jan 1, 1970
0
We have been using The Philips version of ths chip for a while with no
problems. AS they don't seem to be made any more, we moved to the
Atmel equivalent (part number on the chip: 89C51RD2-IM)

However, we are having problems trying to program the Atmel chip using
the serial Intel hex ISP protocol. We never had any problems when
progamming the Philips part using the same programmer (a custom made
unit)

The only change we made was to reduce the programming voltage from
12volt to 5. The PSEN, ALE and EA lines are all exactl as required for
the Philips part.

The programming software when run seems to work OK, The echoed full
dot codes '.' are returned by the chip on every hex sequence sent as
they should. However, when attempting th read the contents of the chip
back, ROM locations 78 to 7F never seem to program correctly, they are
stuck at FFhex. We have tried a batch of five Atmel chips, they all do
exactly the same.

Are we doing something wrong? Are there any essential differences
ebtweeen the Philips programming method and the Atmel one that we
should be aware of??

Thanks in advance

Ted
 
T

Tilmann Reh

Jan 1, 1970
0
ted said:
We have been using The Philips version of ths chip for a while with no
problems. AS they don't seem to be made any more, we moved to the
Atmel equivalent (part number on the chip: 89C51RD2-IM)

However, we are having problems trying to program the Atmel chip using
the serial Intel hex ISP protocol. We never had any problems when
progamming the Philips part using the same programmer (a custom made
unit)
...
Are we doing something wrong? Are there any essential differences
ebtweeen the Philips programming method and the Atmel one that we
should be aware of??

I don't have an answer to your question, just wanted to let you
know that we used the Atmel RD2 without any problems in three
different designs now.
We used FLIP (downloadable from Atmels homepage) or a self-programmed
ISP loader to program the chips.


--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)
 
T

ted

Jan 1, 1970
0
Tilmann Reh said:
I don't have an answer to your question, just wanted to let you
know that we used the Atmel RD2 without any problems in three
different designs now.
We used FLIP (downloadable from Atmels homepage) or a self-programmed
ISP loader to program the chips.
Thanks, I am sure this is not a problem with the Atmel part. I am just
wondering if thre is a difference between the Philips and the Atmel
programming methods

Any ideas?

TIA
 
T

Tilmann Reh

Jan 1, 1970
0
ted said:
Thanks, I am sure this is not a problem with the Atmel part. I am just
wondering if thre is a difference between the Philips and the Atmel
programming methods

That's why I pointed you to FLIP.
I don't have detailed information about your loader, so perhaps
you'd better give FLIP a try, just to see if that works.

I also wanted to test the Philips RD2 in one of our applications,
but since it lacks the internal EEPROM of the Atmel chips, it
was not suitable for this project and I did no further tests.
So I don't know of more differences between the two.
Any ideas?

Only the above...

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)
 
T

ted

Jan 1, 1970
0
Thanks. I found what the problem was. The Intel hex files generated
(by Keil) can start at any address. In one case, the hex record
started at hex 76 and went for 16 bytes, straddling the first 128 byte
EPROM page. The Atmel chip (or at least the batch of chips I got) for
some reason, didn't like this.

I rewrote the loader so that Intel Hex files generated do not cross
page boundaries, so they all start at 0060hex, 0070hex 0080hex and so
on. THis cured the problem..

Very odd that was!!!

Thanks for your help!!

Ted
 
T

Tilmann Reh

Jan 1, 1970
0
ted said:
Thanks. I found what the problem was. The Intel hex files generated
(by Keil) can start at any address. In one case, the hex record
started at hex 76 and went for 16 bytes, straddling the first 128 byte
EPROM page. The Atmel chip (or at least the batch of chips I got) for
some reason, didn't like this.

<BANG> I should have remembered...
I made the same experience one time, when one of my programs would
be programmed only partially. However, it didn't come to my mind
this time...
Yes, the flash is programmed in rows, and all data of one programming
cycle has to be in the same row. FLIP does rearrange the data
if necessary, and my final ISP loader also does... (I never checked
if the Philips chip has the same restrictions.)
I rewrote the loader so that Intel Hex files generated do not cross
page boundaries, so they all start at 0060hex, 0070hex 0080hex and so
on. THis cured the problem..

Yes, for me too.
Very odd that was!!!

Once you know, it's simple and obvious. So simple and obvious that
I obviously forgot...

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)
 
T

ted

Jan 1, 1970
0
Thanks for that

Do you know if this part suffers from the reset brownout problems that
affects the Temic equivalents?

Thanks
 
Top