How to setup Xgate for Interrupt processing

[mac164]

This 'question is no longer valid - I have rewrote the manual.

[GordonD]

Mac,

Like Derrick, I am also a "bare metal enthusiast". I began programming in assembly language when I had to 'had assemble' code and enter the programs as hex bytes on a terminal and have written 10's of thousands of lines of assembly code over my career. I resisted moving to C for a long time, but once I did I've never looked back. I rarely if ever program in assembly language any more. While I don't want to start an assembly vs C discussion, the main reason for the use of a high level language is productivity. Many studies have shown that a programmer can produce only so many lines of debugged, non-comment lines of code per day, regardless of programming language used. And a high level language just allows a programmer to effectively write more code.

I will be the first to admit, that many C programmers write awful code. Most of the C source I have seen, even that used in commercial applications, is very poorly commented and has very poorly chosen variable names. It takes a lot of time to write accurate, meaningful comments and documentation as part of the coding process and this is an area that often just doesn't get done. So, your comments regarding the lack of readability and understanding of other's C code is usually well justified. However, that is not the fault of the language. It's poor programming practice.

That being said, I recently posted a buffered SCI example using XGate in the thread titled "Why Freescale". It is written in C, but hopefully there are enough comments you can understand the code and use it to rewrite it in assembly if you so choose.

Regards,

Gordon

[Chema · Accepted solution]

Hello Gordon,

Please, I have read your previous answer and I would like ask to you as experimented programmer the following:

Is there some basic example of using xgate assembly program? Me as MAC, I want to use only assembler language (I do not understand C and not having time to learn) I need to use only assembler. I just design a MCU for automotive application and install two Freescale XEP100 MCU's.

I try to use the xgate assembler from CodeWarrior and I got error Bxxx "File input format error" or some thing like that. The xgate assembler manual pdf does not answer my needs I do not found it useful. So, I would very much appreciate if some one here can help me to learn how to use the xgate assembler from CodeWarrior. Please, just one basic 3 to 10 assembly instructions that could run on the xgate assembler as a sole file. I already can do the *.asm program.

Thanks very much and best regards from Mexico.

Jose Beltran

[Derrick]

Hi MAC,

The ability to understand someone else’s program has everything to do with the comments which they have provided, regardless of the chosen programming language.  I have taught structured assembly language and embedded C programming.  But it's difficult to convince everyone to comment their code.

Being a bare metal enthusiast, I would be the last one to tell anyone that they must use C.  But over the years I have found that doing so is simply easier and faster.  I have written code for a variety of microcontrollers – 8, 16 and 32 bits – mostly Freescale architectures but also several others (usually for comparative analysis).  Regardless of the target device I invariably end up needing to use some very common routines.  These include drivers for serial interfaces (SCI, SPI, I2C), timer functions (input capture, output compare, PWM), general purpose I/O, Analog-to-Digital Converters, and more.  Writing programs in C simply makes it easier for me to get something up and running on another platform.  It’s not always transparent, but it is quicker.

However, as I state, I’m a bare metal blacksmith.  I’m very accustomed to counting every bit, byte and execution clock cycle of assembly language code.  I spend a considerable amount of time using the disassembly feature in CodeWarrior to make sure that I get the code that I want out of the C compiler.  I’ve done this enough to realize that the compiler only does what it is told and I have learned how to tell it to do what I need.

I prefer to end up with assembly language, rather than to start with it.  To each their own.

As for XGATE, I recommend taking a look at the XGATE application notes that are available on the website.  Most of these include separate software downloads.  Yes, these are written in C.  But if you throw them into CodeWarrior you can use the disassembler and can grab the resulting assembly code.

The S12 architecture supports a single interrupt level.  Part of the CPU’s interrupt acknowledge process involves setting the I-bit in the CCR thereby disabling other interrupts until the current service routine is complete – unless the I-bit is cleared within that routine.  In other words, if you need to nest interrupts then you need to manage it within the
service routines.  However, this needs to be done carefully as it opens the door to the possibility of having a source
interrupt its own service routine.  In some situations this can cause the stack to be quickly overrun.

The interrupt controller in the S12X is structured similar to the ColdFire/68k family and implements seven interrupt priority levels – with 7 being the highest and 1 the lowest (0 disables the interrupt).  These levels facilitate the ability to nest interrupts by allowing those with a higher priority to interrupt others that are lower.  System configuration entails setting the priority level for each available interrupt source and determining whether the interrupt service routine is handled by either the CPU or the XGATE coprocessor.  Either core can handle none, some or all of the interrupts – there is no inherent limit imposed by either processing core.

The S12XE architecture can have as many as 128 interrupt sources.  To save register address space, the interrupt configuration registers are banked into a window that provides access to only eight registers at a time. This should only have an impact on the start up configuration code.

Best Regards,

Derrick

[mac164]

Derrick/Gordon

Thanks for all your help. I've been able to clarify several things from your comments and have learned several.

My XGATE test program uses the Full Simulator only and all Code & Data is located in RAM.

1. In Assembly, you must translate the XGATE_Vector address to the XGATE Local map (by adding $C000) before

writing to the XGVBR.

     MOVB     XGATE_Vector+$C000, XGVBR

2. Only six(6) Software Triggers (SWT) will work when the documentation is followed. I can activate the XAGTE Interrupts for SWTs 2 thru 7, but not 0 or 1. When activating SWT 0 or 1 the Simulator halts and display Exception 70 or 71 (for SWT 0 & 1). SWT 2-7 work fine.

3. I have some more questions if you guys have time to consider them:

Question #1: Is the problem with the SWT with the Simulator Only? Perhaps SWT 0 & 1 will work on a real Chip? Is this a known Eratta?

Question #2: Is there a Assembler directive to switch between Xgate and S12 Assembly. For example on page 468 of the Ref. manual (Rev. 1.23) in an example program there appears to a a directive "CPU XGATE" that que's the Assembler to create code for Xgate. Presumably there would also be a S12 directive.

However the assembler does not recognize CPU XGATE as stated in the example listing. A great deal of Freescale's example programs that I have seen are either useless or error laden. However an example in the Ref. manual that can't be compiled or assembled is not a good sign. I have searched the useless 'help' file to no end and cannot find any such function or directive. It would be a good thing to have such a directive since it would allow both S9 and Xgate to be written in the same file. Apparently the Assembler keys on the extension (ASM & XGATE) only.

The Ref Manual harps on short Xgate Code and the CPU signaling the Xgate (Via ints) and the Xgate signaling he CPU (via Ints) when finished. This doesn't make sense to me for any application.  The purpose of a Co-Processor, as freescale professes the Xgate to be, is to eliminate CPU over head. Having an event interrupting the CPU, who then determins if the Xgate can handle it, then interrupts the Xgate for processing, and is again interrupted when Xgate has completed is rediculous.

Question: Is Freescale hiding some problem with Xgate? Like overheating etc..?  Is there any specification regarding dwell time for the Xgate?

My intent, for purchasing an Xgate processor was/is to run a 256K Baud multiple layer protocol Communication program. (I intend to translate an Intel (IBM PC) device driver that I had developed to Xgate code). The Xgate would run dam near contineuosly Receiving and Transmitting and handle the protocol. The S9CPU would have it's handfull with various primary and house keeping functions. This brings up the subject of Semaphores. The S9CPU would operate under a pseudo Multitasking system and as such utilize it's own semaphores.

However the subject of sharing memory between the S9CPU & XGATE is not very well documented in the Ref. manual.

The Manual states the the CPU has priority when both are addressing the same memory.  This is like saying that "when I decide to drive my car - you must stay at home because I have priority". Perhaps we should say the "when we approach head on, on a one lane bridge, you must back up so I can cross". That way we both get to drive at the same time.

When the CPU is accessing Memory Location $1000, Can the Xgate access $1010. In this case priority access is by Paragraphs (16 bytes) blocks. OR does the CPU block Xgate Access to any RAM when the CPU is accessing any RAM? OR perhaps it works by the 8K fixed RAM or the 2K Paged RAM.  Can the Xgate access Register xx20 while the CPU acesses register xx30 or is all Register access blocked and etc..? Does anyone Know? Is there a manual not accessable from the Freescale site that documents this?

Sorry for the Length - Appreciate any information you may have

Thanks MAC

[GordonD]

Mac,

Sorry for the slow response. I'll try to answer your questions.

1. This is correct when the XGate vector table resides in the CPU12X local map (i.e. 0x1000 - 0x3fff).

2. I don't know why you are having trouble with the software triggers zero and one. In the past, I have used them on the hardware without any problems.

3.1 As I mentioned above, there are no problems with the software triggers.

3.2 CPU12X and XGate code cannot be combined in the same file. Each CPU has its own instruction set and its own assembler. The IDE 'knows' which assembler to use based on the file extension.

3.3 I'm not sure why you might think Freescale is "hiding" something with regard to the XGate CPU relative to "overheating". The specifications for maximum current consumption and the conditions under which it is measured are clearly defined in Section A.1.10, Supply Currents, of the Reference Manual. As you can see from Table A-11, Module Configurations for Maximum Run Supply Current VDD35=5.5V, "XGATE fetches code from RAM, XGATE runs in an infinite loop, reading the Status and Flag registers of CAN’s, SPI’s, SCI’s in sequence and doing some bit manipulation on the data". So it is running continuously.

With regard to sharing data between the two CPUs, it is generally a good idea to utilize the built in hardware semaphores to allow only one of the CPUs to access a shared data structure at a time. However, this is a separate issue from the XGate and CPU12X accessing the on-chip resources "simultaneously". The CPU12X only accesses RAM, for instance, during the e-clock (bus clock) high time. The XGate CPU always has access to the RAM during the E-clock low time. If the CPU12X is not accessing RAM, the XGate CPU can access RAM during both the E-clock high and low time.

So, the XGate CPU can access RAM at twice the rate as the CPU12X. Even if the CPU12X were accessing the RAM every bus cycle (i.e. executing code out of RAM), XGate would still be able to access RAM at the bus clock rate (i.e. every E-clock low cycle).

For the PFlash and I/O registers, there is a priority access mechanism which gives priority to the CPU12X. So, if the CPU12X is accessing PFlash block 1 at the same time as XGate makes an access attempt, XGate will be held off until the CPU12X completes its access. The same thing is true for the I/O register block. For the I/O block, this is generally not much of a problem since, if designed properly, XGate will do the bulk of the I/O processing and communicate results to the CPU12X via a shared data structure in RAM.

I hope this helps.

Regards,

Gordon