Help with Obtaining HCS12 Electrical Characteristics

[sabretooth]

Good evening everyone,

References: A.  MC68HC912D60 Advance Information Manual

B.  Screenshot of ‘D60 Advance Info Manual (Attached)

C.  Discussion Group Thread: “Re: MC9s12DG128 RTI,” posted by Peg, posted on: 2006-03-0104:20 PM

Background.  I’ve recently made a post to the Freescale forums concerning an app I’m working on that involves the clocks and reset generator module (CRG).  In my searches to discover how to ensure I’m implementing proper and safe code for the CRG, I’ve come across several interesting observations:

1.  There exists a good amount of support for developers who use the current variants of the HCS12 family, in terms of Advance Info manuals, product notices, errata fact sheets, application developer links, etc.  What I haven’t been able to stumble across in my searches through the Freescale website are any references that outline detailed electrical characteristics for any HC12 and HCS12 modules developed beyond the MC68HC912D60 as per Reference A above.  As the attached document at Reference B will show, this HC12 device came with an Advance Info manual that included all electrical characteristics for each of the modules on-board.  An example of detailed information that would prove useful if I was using this module for my particular app is found on p.360, Table 74 (things like the “limp home” frequency range, min bus freq, etc, are good to know .

2.  Other useful info that this manual outlined at Reference A contained were sections on development support including info on BDM and breakpoints, as well as a section on “CGM Practial Aspects.”  For future releases of the HC12 and HCS12, why wasn’t this information updated and incorporated into the advance info manuals?

3.  After browsing through the ‘DP256B advance info manual, and CRG block user guide, I cannot come anywhere close to identifying the same kinds of information as that discovered at Reference A above.  Why is this?  Where can I find this information?   Most chips, ICs, electronic devices etc are accompanied with a datasheet, what happened to the detailed datasheet-type information for the HC12 and HCS12 devices?  From the post identified at Reference C, mention was made of a “DG Manual” which contains the kind of info I’m searching for (this discussion thread pertained to an app that made use of the MC9s12DG128 RTI, while this isn’t the same as my app, the contents of the discussion are similar to my problem).  Where can I find this “DG Manual?”  Is it called something else depending on which HCS12 target I’m using?

Summary.  I’d like to request that critical design and operating characteristic information be made available to the HC12 and HCS12 community.  If this information cannot be provided as “open source,” the community (in my humble opinion, of course) would like to at least be told how much it will cost or if it simply cannot be provided due to liability and trade control issues with regard to sharing, access and use of this type of information.

Can anyone from Freescale offer any insight as to where to find this information?  Can anyone who uses this forum point me in the direction of the people at Freescale who normally have access to this info?  Most importantly, who else out there has experienced similar problems at tracking down the electrical characteristics of their device?!?!

Eric

[Alban]

Hello Eric,

HC12 and S12 are two different product lines using a different technology.

1. There is nothing attached, but I see what you mean. On the S12 family, the Electrical Characteristics are placed at the end of each Datasheet.

2. A guide for HC12 does not always apply for S12. S12 core has a lot of Application Notes and Engineering Bulletin which will explain the CRG for instance. Each datasheet shows a PCB layout example also.

3. The S12DG128 is covered by the S12DT128 datasheet. see link below

Data Sheets

ID and Description	Vendor ID	Format	Size K	Rev #	Date Last Modified
9S12DT128DGV2 9S12DT128(E), 9S12DG128(E), 9S12DJ128(E), 9S12DB128 Device Guide	FREESCALE	pdf	6464	15	11/21/2005
9S12DT128_ZIP MC9S12DT128 Zipped Files	FREESCALE	zip	6793	13	11/21/2005
HCS12DFAMILYPP HCS12 D-Family Product Proposal	FREESCALE	pdf	413	6.1	10/23/2002
READ-ME_HCS12 READ-ME_HCS12 -- HCS12 Document Methodology	FREESCALE	pdf	224	0.2	7/09/2003

The point of entry for information request is the Techical Information Centre and not individual FSL employees. You can also posts questions on this Forum.

The first reason being that nobody can be specialist in all products. (It's not called a speciality anymore in this case).

Cheers,

Alban.

[sabretooth]

Alban,

Thank-you very much for your response!  I of course realize (too late mind you) that there were several errors with my post, most notably my forgetting to attach the file I promised, in addition to mentioning that my specific problem concerning an apparent lack of documentation is in regard to the 'HC9S12DP256B.  After doing some searching of the Freescale documents, I've come across several Data Sheets and product notices for many HCS12 variants, all save for the 'DP256B.  It may be that I'm not performing the correct search, however if you know where I might find the docs you pointed to in your post for my specific uC, I'd be very grateful.

I have a second question that has since spawned off of the discussion above; it has to do with the Errata Pages.  I've managed to find the errata page specific to my mask set, however I was wondering if you know of a way to get automatically updated via e-mail if and when anything is added to my particular errata page.  In addition, would it be possible to be notified via e-mail if any new PCNs (product change notices) come out, or are the mailing lists only specific down to a particular architecture (ie: 16-bit mailing list, motor control mailing list, etc).

Finally, I have a few new follow-on questions regarding interrupt latency in terms of best, avg, and worst case clock cycles.  The following are a short list of assumptions and one question made in regard to interrupt latency for my particular case:

1.  I have a system that requires I know how long it will take for the highest priority, maskable interrupt to process upon assertion of the applicable interrupt flag.  This includes:

 A.  Finishing whatever current instruction is in the pipe;

 B.  Saving context info to the stack (I assume that this portion of the latency calculation should remain constant in all cases);

 C.  Vectoring to the location of the ISR; and

 D.  Performing any stack framing ops (compiler specific; I assume that I will be able to work this portion of the calculation out for myself) prior to actually getting to my ISR-specific code, such as clearing the applicable interrupt flag to avoid an SWI.  As an additional follow-on question, any specific info concerning the SWI instruction that you could point me towards would be very beneficial for me to further understand how it works; I've read the HC12 instruction book and I still have a hard time understanding how this instruction works.

2.  I assume that no other non-maskable interrupts will be firing at the same time so as to override my high-priority, maskable interrupt.  A blind assumption, I know, as we all know that resets and other pwr problems can happen at any time...

3.  Based on information gathered from the CRG module pages of the 'DP256 Advance Info page, the Star12 core operates at either PLL or OSCCLK frequency, which is double that of clk3 (or inter-module bus) freq.

From the assumptions above, what values can I arrive at for best, avg, and worst case clock cycles prior to being able to execute my ISR code?

Thanks again for your help and pointers to device manuals!

Eric

[Alban]

Hello Eric,

You can stay informed of the products by email automatically.

This includes Datasheet, Application Notes, Engineering Bulletin, Errata Sheet... Not sure about PCN but as I've never received any, I don't think so. You probably can request to be added to a notification list for PCN.

I receive the update weekly via an email titles "News from Freescale Semiconductor"

• Login to your Freescale Interest profile

• S12DP256B Product Page
• This is an older product by its Flash technology. I advise you use S12DP256 or S12DP256E (RoHS, PbFree).

Data Sheets ID and Description Vendor ID Format Size K Rev # Date Last Modified 9S12DP256B-ZIP MC9S12DP256B Users Guide, zip format   FREESCALE   zip   3715   2.15   6/04/2003   9S12DP256BDGV2 9S12Dx256B Device Guide, also covers C derivatives and 9S12Ax256 devices   FREESCALE   pdf   3405   15   1/25/2003   HCS12DFAMILYPP HCS12 D-Family Product Proposal   FREESCALE   pdf   413   6.1   10/23/2002   READ-ME_HCS12 READ-ME_HCS12 -- HCS12 Document Methodology   FREESCALE   pdf   224   0.2   7/09/2003

1A. CPU12 reference manual gives that time.

1B: Fixed yes,

1C. Fixed as well: address fetched.

2. As said by Bigmac, this only occur if you intentionally authorize interrupt nesting.

3. There is a divider by 2 between clock source (PLL or XTAL) and the bus, yes. But instructions are executed at bus clock, so clock source speed is not used to calculate timings.
By referencing to Bus Clock you will be able to easily translate to any clock source with having to divide things...

Cheers,

Alban.

[sabretooth]

Alban,

Thanks again for your help!  I'll have some reading to do over the weekend concerning the info you presented.

[peg]

Hi Eric,

Just wondering,

As we don't know what timezone you live in, I'm wondering why you are wondering if anybody else is wondering whether your posts are occurring outside of your business hours.

Regards

Peg

[sabretooth]

Peg,

Ha ha, I see your point!  I'm at GMT-5 during the winter months, and GMT-6 during the summer.  Now for a more descriptive and somewhat less nerdy response:

I enrolled in the Canadian Forces (CF) under the Regular Officer Training Plan in June, 1998.  I received my Commission effective May, 2002, after obtaining a BEng from the Royal Military College located in Kingston, Ontario, Canada.  Following my occupation training as an Aerospace Engineer, I spent three awesome years in Cold Lake, Alberta, Canada serving with several operational units who maintain and fly the CF-188 Hornet aircraft.  I presently work in Ottawa, Ontario, Canada as the Integrated Logistics Support manager for the CF-188 Night Vision Imaging System project.

So that's me, what about you?

[bigmac]

Hello Eric,

1.  SWI is a single byte instruction that initiates similar actions to a hardware interrupt, where vectoring to an ISR will occur whenever the command is encountered.  A software interrupt can never occur unless you actually use the SWI instruction - there might be some confusion about this.  The SWI instruction has been tradidionally used by monitor programs, during debug processes.  When the program to be debugged is located in RAM, the substitution of a SWI instruction is used to implement a breakpoint.

2.  For worst case interrupt latency, you would also need to take into account the longest ISR processing time for any of the other interrupts that may currently be enabled.  This is because all interrupts are usually disabled during ISR processing.  If another interrupt (of any priority) were to occur just prior your priority interrupt, the priority interrupt would not be entered until the completion of this other ISR.  This is a good reason to keep all ISRs very short.

It is possible to re-enable interrupts within the "other" ISRs (for an interrupt within an interrupt), but this is not to be undertaken lightly.  The additional code required to prepare for this situation (individually disabling all other non-priority interrupts) will add to the latency.

Regards,

Mac

[sabretooth]

Mac,

Well put.  Although I have to admit I'm still confused regarding your first comment about the "SWI."  If I can be permitted to drill down into the Adv Info for the 'DP256, at p.143 the liturature states: "Before masking an interrupt by clearing the corresponding local enable bit, it is required to set the I-bit to avoid an SWI."  Reading this, I assumed that the hardware developers are implying that if one interrupt source fires, then a second fires immediately after and just prior to the first interrupt being allowed to clear its applicable flag in its ISR code, an ambiguity will arise as to which interrupt caused the ISR.  I can think of where this would be a problem, notably the SCI and ECT which have multiple interrupt sources within their respective modules that are "OR'd" together and then fed to a common interrupt output. 

Looking at p.425 of 'DP256 Adv Info: "the SCI only has a single interrupt line (sci_int, active high operation) and all the following interrupts, when generated, are ORed together and issued through that port."

I've actually seen the results of this happen a number of years ago when two signals fired almost concurrently that were connected to TC0 and TC1 respectively.  I coudn't see what was going on until I put a vector to a valid ISR for the SWI, and then trapped a few "SWI" interrupts when both signals "overlapped."  At least that's what I assumed was happening.

If you have any other amplifying info on the SWI within the context I presented above, please let me know.  Maybe I'm just totally out to lunch which does happen from time-to-time.

If anyone wonders why my posts happen after-hours, its coz I can't make this stuff part of my day-to-day work... at this time...

Eric