DEMO9S12XDT512 oscilator (Part 2)

[khumphri]

Continued from DEMO9S12XDT512 oscilator (Part 1)

This message contains an entire topic ported from a separate forum. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value to you as you search for answers to your questions.

Posted: Thu Jan 12, 2006 11:23am

> > Look at the PLL jitter specs and tell me where the problem is - I didn't find any.
>
> The specs does not tell all. In my case where I used the byteflight

I measured less jitter than specified.

> in the 9S12DB128 with PLL. The byte flight was useless when using a
> PLL at full speed, jitter was too much so I have to use can oscillator, more stable.

That's interesting. Maybe it's because Byteflight is much faster than CAN. I never had problems with CAN at speeds between 125kBits/s and 1MBit/s, and with the (low) PLL jitter there shouldn't be any problem unless you try to go to the limits (1MBit/s with long cable).

---

Posted: Mon Jan 16, 2006 7:47pm

I thought I had read about this somewhere....I just came across this again in the MC9S12XDP512_V2.pdf page 596....

"If the bus clock is generated from a PLL, it is recommended to select the oscillator clock rather than the bus clock due to jitter considerations, especially at the faster CAN bus rates."

So, somebody at Freescale thinks the PLL has too much jitter for high speed CAN.

We plan to run CAN off the osc clock with a 16MHz xtal instead of 4MHz for this reason.

Does anyone else have any more information on this subject?
Is anyone else running 1Mb/S CAN from the PLL? What oscillator type and PLL register settings are you using?

---

Posted: Thursday, January 12, 2006 12:24 PM

> > Look at the PLL jitter specs and tell me where the problem is - I didn't find any.
>
> The specs does not tell all. In my case where I used the byteflight

I measured less jitter than specified.

> in the 9S12DB128 with PLL. The byte flight was useless when using a
> PLL at full speed, jitter was too much so I have to use can oscillator, more stable.

That's interesting. Maybe it's because Byteflight is much faster than CAN. I never had problems with CAN at speeds between 125kBits/s and 1MBit/s, and with the (low) PLL jitter there shouldn't be any problem unless you try to go to the limits (1MBit/s with long cable).

 

Posted: Thu Jan 19, 2006 3:33am

> I thought I had read about this somewhere....I just came across this again
> in the MC9S12XDP512_V2.pdf page 596....
>
> "If the bus clock is generated from a PLL, it is recommended to select the
> oscillator clock rather than the bus clock due to jitter considerations, especially

> at the faster CAN bus rates."
>
> So, somebody at Freescale thinks the PLL has too much jitter for high speed
> CAN.

Maybe that's true, but maybe the simply didn't want to verify and/or guarantee that it works with PLL.

I measured a similar low jitter as Edward reported. And if you read the jitter specs, you will find that the PLL is pretty stable.

But I will not do the proof (calculation) for you, I'm as lazy/cautious as Motorola <g>.

P.S.: We use CAN and PLL up to 1MBit/s (8MHz Xtal, HC12D60A and 9S12D).

Posted: Thu Jan 12, 2006 5:33am

> [PLL?]
>
>> 4*4MHz PLL is not equivalent to 16MHz OSC clock at least for 2 reasons:
>>
>> 1) What about PLL jitter and CAN @ 1Mbps? Should be OK but with higher
>
> Look at the PLL jitter specs and tell me where the problem is - I didn't find any.

No problem, it was just a clue to Q:"why someone may want fast oscilator instead of slow.osc+PLL?".

Posted: Wed Jan 11, 2006 6:26pm 

After reading through the posts on problems with inadvertently securing the HC12 part, I think that is what has happened to us using the compod12 or else the pod has failed for some reason. I have experienced this symptom before with the P&E multilink but P&E has a program to unsecure the part; we can't find any such program for the compod12. Everything was working ok, then an error occurred during flashing and now the part can't be loaded; but the processor run fine and the last flashed code works.

Would anyone have a program to unsecure the 9s12dg128b using the compod12 or advise they can share? We have a compod12 at one location (serial port version) and can't find any program similiar to the P&E multilink unsecure. The P&E version won't work with compod12 of course. Elektronikladen has a compod12 pro version that talks about an unsecure function but we don't have that pod and the software isn't on their site that we can see. It's a question of time and delays and getting a new pod or shipping one we have. Thanks

Posted: Wed Jan 11, 2006 7:09pm

Have you email'ed Oliver at elmicro? He should be able to tell you about what StarProg can or cannot do.

At 04:26 PM 1/11/2006, XXXX wrote:

>After reading through the posts on problems with
>inadvertently securing the HC12 part, I think that is what
>has happened to us using the compod12 or else the pod has
>failed for some reason. I have experienced this symptom
>before with the P&E multilink but P&E has a program to
>unsecure the part; we can't find any such program for the
>compod12. Everything was working ok, then an error occurred
>during flashing and now the part can't be loaded; but the
>processor run fine and the last flashed code works.
>
>Would anyone have a program to unsecure the 9s12dg128b using
>the compod12 or advise they can share? We have a compod12 at
>one location (serial port version) and can't find any
>program similiar to the P&E multilink unsecure. The P&E
>version won't work with compod12 of course. Elektronikladen
>has a compod12 pro version that talks about an unsecure
>function but we don't have that pod and the software isn't
>on their site that we can see. It's a question of time and
>delays and getting a new pod or shipping one we have. Thanks

 

Posted: Thu Jan 12, 2006 2:10am

You can try my debugger/programmer package HC12ICD hc12icd.zip for unsecuring your target device with ComPOD12:

from http://www.krummsdorf.de/hc12icd/downlo_e.html

See instructions in http://www.krummsdorf.de/files/first.pdf . Sorry, it's a bit outdated
Pls regard: The "SSC Reset" box for doing a special single chip reset by every reset is moved to "Setup/Options/Startup" and it is no more necessary to do the unsecure function twice !

To enable the device security menu "File/Device Security" in the demo version change in the "hc12icd.ini" :

[HC12ICD]
FLBBDEMO=0.

and then start the hc12icd.exe once more.

You can also adjust the values for the word at the memory location 0xFF0E in
the "hc12icd.ini"

[HC12ICD]
SECURE_WORD=FFFC
UNSECURE_WORD=FFFE

if the part is secured or not.

Good luck and regards

Posted: Thu Jan 12, 2006 5:08pm

run StarProg and click the "unsecure" icon for S/W updates follow http://www.google.com/search?q=compod12

> After reading through the posts on problems with
> inadvertently securing the HC12 part, I think that is what
> has happened to us using the compod12 or else the pod has
> failed for some reason. I have experienced this symptom
> before with the P&E multilink but P&E has a program to
> unsecure the part; we can't find any such program for the
> compod12. Everything was working ok, then an error occurred
> during flashing and now the part can't be loaded; but the
> processor run fine and the last flashed code works.
>
> Would anyone have a program to unsecure the 9s12dg128b using
> the compod12 or advise they can share? We have a compod12 at
> one location (serial port version) and can't find any
> program similiar to the P&E multilink unsecure. The P&E
> version won't work with compod12 of course. Elektronikladen
> has a compod12 pro version that talks about an unsecure
> function but we don't have that pod and the software isn't
> on their site that we can see. It's a question of time and
> delays and getting a new pod or shipping one we have. Thanks