DJ64 eeprom programming in low temperature

We are using HCS12 micro ( MCS12DJ64 CPV 2L86D mask set) in our
automotive CAN application . Recently, we have discovered some
problem with eeprom programming in low temperature ( -20 degree
Celsius ) environment. Our automotive application is programmed to
write some datum to DJ64s eeprom before turning the power off . The
application runs fine in room temperature ( 10 V 20 degree
Celsius) , all the datum has been written correctly to DJ64 eeprom,
however, when the same application runs in low temperature
situation, eeprom programming did not get any error flag from DJ64 ,
but the result of eeprom programming showed some disparity when
comparing with the source datum. For example, input data stream:
0x94 0xFD 0xE0 0x03 might become 0x95 0xFD 0x00 0x00 in eeprom after
programming. This happens every time when the application runs in
low temperature. Weve tried with at least 10 different micros, and
they all displayed the same kind of symptoms in the low temperature
situation. Any comments or suggestion are greatly appreciated! Here
are some infos regarding our eeprom programming settings:

Oscillator clock: 10M Hz
bus clock: 10 M Hz ( Tbus = 0.1 us , according S12EEETS4KV docs)
PLL flag is turned on
ECLKDIV register: we tried with 0xB9 , 0xB6 and both got
the same erroneous result
Eeprom command used: 0x40 ( sector erase), 0x20 ( program a
word)

Eeprom programming method: blank a sector ( 4 bytes), then
program 2 words., repeat the same process until the source data
stream is done.

Joe Soo Start a New Thread

--- In 6..., "jo_wan_soo" wrote:
>
> We are using HCS12 micro ( MCS12DJ64 CPV 2L86D mask set) in our
> automotive CAN application . Recently, we have discovered some
> problem with eeprom programming in low temperature ( -20 degree
> Celsius ) environment. Our automotive application is programmed
to
> write some datum to DJ64s eeprom before turning the power off .

> Oscillator clock: 10M Hz
> bus clock: 10 M Hz ( Tbus = 0.1 us , according S12EEETS4KV
docs)
> PLL flag is turned on
> ECLKDIV register: we tried with 0xB9 , 0xB6 and both got
> the same erroneous result
> Eeprom command used: 0x40 ( sector erase), 0x20 ( program a
> word)
>
> Joe Soo
>
I hope someone else can directly answer your temperature question.
You have me concerned about our low temp operation...
First, I would quadruple check your ECLKDIV math to make sure you are
running at the correct frequency. Are you sure your OSCCLK and BUS
CLOCK are both 10MHz? Unless you are using the PLL, your BUS CLK
would be 1/2 the OSCCLK. What are your PLL settings? Also, how did
you calculate the 0xB9 and 0xB6 ECLKDIV values? I calculate a value
of 0x32 (note you don't need to write the EDIVLD bit).
Please let us know if you find the problem. Start a New Thread

At 01:56 AM 11/23/2006, you wrote:
> We are using HCS12 micro ( MCS12DJ64 CPV 2L86D mask set) in our
>automotive CAN application . Recently, we have discovered some
>problem with eeprom programming in low temperature ( -20 degree
>Celsius ) environment. Our automotive application is programmed to
>write some datum to DJ64s eeprom before turning the power off . The
>application runs fine in room temperature ( 10 V 20 degree
>Celsius) , all the datum has been written correctly to DJ64 eeprom,
>however, when the same application runs in low temperature
>situation, eeprom programming did not get any error flag from DJ64 ,
>but the result of eeprom programming showed some disparity when
>comparing with the source datum. For example, input data stream:
>0x94 0xFD 0xE0 0x03 might become 0x95 0xFD 0x00 0x00 in eeprom after
>programming. This happens every time when the application runs in
>low temperature. Weve tried with at least 10 different micros, and
>they all displayed the same kind of symptoms in the low temperature
>situation. Any comments or suggestion are greatly appreciated! Here
>are some infos regarding our eeprom programming settings:
>
> Oscillator clock: 10M Hz
> bus clock: 10 M Hz ( Tbus = 0.1 us , according S12EEETS4KV docs)
> PLL flag is turned on
> ECLKDIV register: we tried with 0xB9 , 0xB6 and both got
>the same erroneous result
> Eeprom command used: 0x40 ( sector erase), 0x20 ( program a
>word)
>
> Eeprom programming method: blank a sector ( 4 bytes), then
>program 2 words., repeat the same process until the source data
>stream is done.
>
>Joe Soo

Some things to try:

Are you sure that the clock is stable at low temperatures? An unstable
clock causes CPU malfunction.

If you can, turn on ECLK output and look at it. It should be very stable.

Also look carefully (and suspiciously) at the errata for mask set 2L86D. I
didn't see anything directly applicable, but there are some EEPROM errata.

If possible, try the programming without the PLL.

Steve Russell
Nohau Emulators Start a New Thread

we've turned on PLL flag, that's why we have both BUS CLK and OSCCLK
= 10 MHZ. And yes you are right about ECLKDIV calcuation, the correct
EECLK = 196 K or 0x32 (EDIV[5:0]) or ECLKDIV = 0xB2. Since this
eeprom clock value is very close to the margin of workable eeprom
programming frequency range ( 150K - 200K), we've tried with EECLK
value that's closer to the middle of the range , EECLK0K or 0x39
(EDIV[5:0]) or ECLKDIV =0xB9 , ECLK0K or 0x36(EDIV[5:0]) or
ECLKDIV=0xB6 , but unfortunately, different ECLKDIV settings
(ECLK6K, 170K, 180K) brings the same erroneous eeprom result in
low temperature.

Joe Soo

--- In 6..., "eqh2" wrote:
>
> --- In 6..., "jo_wan_soo" wrote:
> >
> > We are using HCS12 micro ( MCS12DJ64 CPV 2L86D mask set) in
our
> > automotive CAN application . Recently, we have discovered some
> > problem with eeprom programming in low temperature ( -20 degree
> > Celsius ) environment. Our automotive application is programmed
> to
> > write some datum to DJ64s eeprom before turning the power off .
>
> > Oscillator clock: 10M Hz
> > bus clock: 10 M Hz ( Tbus = 0.1 us , according S12EEETS4KV
> docs)
> > PLL flag is turned on
> > ECLKDIV register: we tried with 0xB9 , 0xB6 and both got
> > the same erroneous result
> > Eeprom command used: 0x40 ( sector erase), 0x20 ( program a
> > word)
> >
> > Joe Soo
> >
> I hope someone else can directly answer your temperature question.
> You have me concerned about our low temp operation...
> First, I would quadruple check your ECLKDIV math to make sure you
are
> running at the correct frequency. Are you sure your OSCCLK and BUS
> CLOCK are both 10MHz? Unless you are using the PLL, your BUS CLK
> would be 1/2 the OSCCLK. What are your PLL settings? Also, how did
> you calculate the 0xB9 and 0xB6 ECLKDIV values? I calculate a value
> of 0x32 (note you don't need to write the EDIVLD bit).
> Please let us know if you find the problem.
> Start a New Thread

We've a scope with probe attached to the crystal working with dj64
controller and measure the clock frequency, it seemed to be rather
stable under low temperature . I don't quite understand about turning
on the ECLK output ? We've also looked up the errata for DJ64 2L86D
mask set, it has 1 related eeprom programming item and it is about
using sector modify command, but we did not use sector modify command
in our software at all. We've used sector erase and program word
commands for eeprom programming in our software. We shall give a try
with running program with no PLL , thanks very much for your help.

Joe Soo

--- In 6..., Steve Russell wrote:
>
> At 01:56 AM 11/23/2006, you wrote:
> > We are using HCS12 micro ( MCS12DJ64 CPV 2L86D mask set) in
our
> >automotive CAN application . Recently, we have discovered some
> >problem with eeprom programming in low temperature ( -20 degree
> >Celsius ) environment. Our automotive application is programmed
to
> >write some datum to DJ64s eeprom before turning the power off .
The
> >application runs fine in room temperature ( 10 V 20 degree
> >Celsius) , all the datum has been written correctly to DJ64 eeprom,
> >however, when the same application runs in low temperature
> >situation, eeprom programming did not get any error flag from
DJ64 ,
> >but the result of eeprom programming showed some disparity when
> >comparing with the source datum. For example, input data stream:
> >0x94 0xFD 0xE0 0x03 might become 0x95 0xFD 0x00 0x00 in eeprom
after
> >programming. This happens every time when the application runs in
> >low temperature. Weve tried with at least 10 different micros,
and
> >they all displayed the same kind of symptoms in the low temperature
> >situation. Any comments or suggestion are greatly appreciated! Here
> >are some infos regarding our eeprom programming settings:
> >
> > Oscillator clock: 10M Hz
> > bus clock: 10 M Hz ( Tbus = 0.1 us , according S12EEETS4KV
docs)
> > PLL flag is turned on
> > ECLKDIV register: we tried with 0xB9 , 0xB6 and both got
> >the same erroneous result
> > Eeprom command used: 0x40 ( sector erase), 0x20 ( program a
> >word)
> >
> > Eeprom programming method: blank a sector ( 4 bytes), then
> >program 2 words., repeat the same process until the source data
> >stream is done.
> >
> >Joe Soo
>
> Some things to try:
>
> Are you sure that the clock is stable at low temperatures? An
unstable
> clock causes CPU malfunction.
>
> If you can, turn on ECLK output and look at it. It should be very
stable.
>
> Also look carefully (and suspiciously) at the errata for mask set
2L86D. I
> didn't see anything directly applicable, but there are some EEPROM
errata.
>
> If possible, try the programming without the PLL.
>
> Steve Russell
> Nohau Emulators
> Start a New Thread

--- In 6..., "jo_wan_soo" wrote:
>
> We've a scope with probe attached to the crystal working with dj64
> controller and measure the clock frequency, it seemed to be rather
> stable under low temperature . I don't quite understand about turning
> on the ECLK output ?
>
> Joe Soo

Your chip has an ECLK output pin shared with Port E4. I'm not sure how
you configure that on your chip (on the MC9S12XDT256 you clear the
NECLK bit in the ECLKCTL register) but when you turn it on, you will be
able to see your bus clock frequency with a scope on that pin.

-Dan Start a New Thread

Some further notes below.

Steve Russell
Nohau Emulators

At 12:11 AM 11/28/2006, jo_wan_soo wrote:
>We've a scope with probe attached to the crystal working with dj64
>controller and measure the clock frequency, it seemed to be rather
>stable under low temperature . I don't quite understand about turning
>on the ECLK output ?

The ECLK output is an option for PE4. It is the bus clock intended for use
with external memory. As it should be a nice, boringly stable, square
clock signal derived from the internal clocks, it is a good indicator that
the internal clocking is working correctly.

ECLK is a better indication than looking at the crystal directly for
several reasons:

The scope probe loads the crystal circuit some and may change the operating
point of the oscillator.

ECLK also comes from internal clocks AFTER the PLL and so will indicate if
the PLL is misbehaving. (If the PLL is not locked, the PLL frequency will
vary rapidly and the MCU just won't work right.)

Finally, it is a normal output signal so that almost any scope will display
it correctly without any fussing.

The NECLK bit in the PEAR register controls the pin usage, and DDRE needs
to enable it for output.

>We've also looked up the errata for DJ64 2L86D
>mask set, it has 1 related eeprom programming item and it is about
>using sector modify command, but we did not use sector modify command
>in our software at all. We've used sector erase and program word
>commands for eeprom programming in our software. We shall give a try
>with running program with no PLL , thanks very much for your help.
>
>Joe Soo
>
>--- In 6..., Steve Russell wrote:
> >
> > At 01:56 AM 11/23/2006, you wrote:
> > > We are using HCS12 micro ( MCS12DJ64 CPV 2L86D mask set) in
>our
> > >automotive CAN application . Recently, we have discovered some
> > >problem with eeprom programming in low temperature ( -20 degree
> > >Celsius ) environment. Our automotive application is programmed
>to
> > >write some datum to DJ64s eeprom before turning the power off .
>The
> > >application runs fine in room temperature ( 10 V 20 degree
> > >Celsius) , all the datum has been written correctly to DJ64 eeprom,
> > >however, when the same application runs in low temperature
> > >situation, eeprom programming did not get any error flag from
>DJ64 ,
> > >but the result of eeprom programming showed some disparity when
> > >comparing with the source datum. For example, input data stream:
> > >0x94 0xFD 0xE0 0x03 might become 0x95 0xFD 0x00 0x00 in eeprom
>after
> > >programming. This happens every time when the application runs in
> > >low temperature. Weve tried with at least 10 different micros,
>and
> > >they all displayed the same kind of symptoms in the low temperature
> > >situation. Any comments or suggestion are greatly appreciated! Here
> > >are some infos regarding our eeprom programming settings:
> > >
> > > Oscillator clock: 10M Hz
> > > bus clock: 10 M Hz ( Tbus = 0.1 us , according S12EEETS4KV
>docs)
> > > PLL flag is turned on
> > > ECLKDIV register: we tried with 0xB9 , 0xB6 and both got
> > >the same erroneous result
> > > Eeprom command used: 0x40 ( sector erase), 0x20 ( program a
> > >word)
> > >
> > > Eeprom programming method: blank a sector ( 4 bytes), then
> > >program 2 words., repeat the same process until the source data
> > >stream is done.
> > >
> > >Joe Soo
> >
> > Some things to try:
> >
> > Are you sure that the clock is stable at low temperatures? An
>unstable
> > clock causes CPU malfunction.
> >
> > If you can, turn on ECLK output and look at it. It should be very
>stable.
> >
> > Also look carefully (and suspiciously) at the errata for mask set
>2L86D. I
> > didn't see anything directly applicable, but there are some EEPROM
>errata.
> >
> > If possible, try the programming without the PLL.
> >
> > Steve Russell
> > Nohau Emulators
> >Yahoo! Groups Links
> Start a New Thread

With out seeing your code I am guessing but my guess is you are
trying to do 2 writes to the ECLKDIV register. Some people try to
write the divide by 8 bit first, then try to write the rest of the
divide values. If you have the BDM connected (special mode) you will
have the correct value in the ECLKDIV register since you can then
write to that register as many times as you like but when the code is
running in normal mode the second write will not take affect.
Regards,
Darci

--- In 6..., Steve Russell wrote:
>
> Some further notes below.
>
> Steve Russell
> Nohau Emulators
>
> At 12:11 AM 11/28/2006, jo_wan_soo wrote:
> >We've a scope with probe attached to the crystal working with dj64
> >controller and measure the clock frequency, it seemed to be rather
> >stable under low temperature . I don't quite understand about
turning
> >on the ECLK output ?
>
> The ECLK output is an option for PE4. It is the bus clock intended
for use
> with external memory. As it should be a nice, boringly stable,
square
> clock signal derived from the internal clocks, it is a good
indicator that
> the internal clocking is working correctly.
>
> ECLK is a better indication than looking at the crystal directly
for
> several reasons:
>
> The scope probe loads the crystal circuit some and may change the
operating
> point of the oscillator.
>
> ECLK also comes from internal clocks AFTER the PLL and so will
indicate if
> the PLL is misbehaving. (If the PLL is not locked, the PLL
frequency will
> vary rapidly and the MCU just won't work right.)
>
> Finally, it is a normal output signal so that almost any scope will
display
> it correctly without any fussing.
>
> The NECLK bit in the PEAR register controls the pin usage, and DDRE
needs
> to enable it for output.
>
> >We've also looked up the errata for DJ64 2L86D
> >mask set, it has 1 related eeprom programming item and it is about
> >using sector modify command, but we did not use sector modify
command
> >in our software at all. We've used sector erase and program word
> >commands for eeprom programming in our software. We shall give a
try
> >with running program with no PLL , thanks very much for your help.
> >
> >Joe Soo
> >
> >--- In 6..., Steve Russell wrote:
> > >
> > > At 01:56 AM 11/23/2006, you wrote:
> > > > We are using HCS12 micro ( MCS12DJ64 CPV 2L86D mask set)
in
> >our
> > > >automotive CAN application . Recently, we have discovered some
> > > >problem with eeprom programming in low temperature ( -20 degree
> > > >Celsius ) environment. Our automotive application is
programmed
> >to
> > > >write some datum to DJ64s eeprom before turning the power
off .
> >The
> > > >application runs fine in room temperature ( 10 V 20 degree
> > > >Celsius) , all the datum has been written correctly to DJ64
eeprom,
> > > >however, when the same application runs in low temperature
> > > >situation, eeprom programming did not get any error flag from
> >DJ64 ,
> > > >but the result of eeprom programming showed some disparity
when
> > > >comparing with the source datum. For example, input data
stream:
> > > >0x94 0xFD 0xE0 0x03 might become 0x95 0xFD 0x00 0x00 in eeprom
> >after
> > > >programming. This happens every time when the application
runs in
> > > >low temperature. Weve tried with at least 10 different
micros,
> >and
> > > >they all displayed the same kind of symptoms in the low
temperature
> > > >situation. Any comments or suggestion are greatly appreciated!
Here
> > > >are some infos regarding our eeprom programming settings:
> > > >
> > > > Oscillator clock: 10M Hz
> > > > bus clock: 10 M Hz ( Tbus = 0.1 us , according
S12EEETS4KV
> >docs)
> > > > PLL flag is turned on
> > > > ECLKDIV register: we tried with 0xB9 , 0xB6 and
both got
> > > >the same erroneous result
> > > > Eeprom command used: 0x40 ( sector erase), 0x20 (
program a
> > > >word)
> > > >
> > > > Eeprom programming method: blank a sector ( 4 bytes),
then
> > > >program 2 words., repeat the same process until the source data
> > > >stream is done.
> > > >
> > > >Joe Soo
> > >
> > > Some things to try:
> > >
> > > Are you sure that the clock is stable at low temperatures? An
> >unstable
> > > clock causes CPU malfunction.
> > >
> > > If you can, turn on ECLK output and look at it. It should be
very
> >stable.
> > >
> > > Also look carefully (and suspiciously) at the errata for mask
set
> >2L86D. I
> > > didn't see anything directly applicable, but there are some
EEPROM
> >errata.
> > >
> > > If possible, try the programming without the PLL.
> > >
> > > Steve Russell
> > > Nohau Emulators
> > >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> Start a New Thread

--- In 6..., Steve Russell wrote:
> The NECLK bit in the PEAR register controls the pin usage, and
> DDRE needs to enable it for output.

I thought the NECLK=0 overrides the DDRE setting. I've always seen
ECLK output on my DP256B, and didn't think I was enabling PE4 as
output in DDRE. Start a New Thread

At 07:53 AM 12/1/2006, you wrote:
>--- In 6..., Steve Russell wrote:
> > The NECLK bit in the PEAR register controls the pin usage, and
> > DDRE needs to enable it for output.
>
>I thought the NECLK=0 overrides the DDRE setting. I've always seen
>ECLK output on my DP256B, and didn't think I was enabling PE4 as
>output in DDRE.

You are correct.

I had forgotten that, and when writing my Email did not read the general
description of the PEAR register, which clearly says that the port E
alternate functions selected by the PEAR setting override that DDRE settings.

Steve Russell Start a New Thread