XGate on the MC9S12XA256: Can it be disabled initially?

cancel
Showing results for 
Search instead for 
Did you mean: 

XGate on the MC9S12XA256: Can it be disabled initially?

Jump to solution
1,534 Views
jacwit
Contributor I

I am trying to determine if I can port my application from a MC9S12A256 to a MC9S12XA256 without needing to turn on/use Xgate initially. My intent is to get the app ported and get it up and running quickly without having to partition it up to run on Xgate. As time permits I will begin to utilize XGate's features.

 

AN3224 hints that this is possible. I am hoping someone has actually done it and/or can shed some insight so that I can provide meaniningful schedule estimates to management. I am in the process of getting mydevelopment tools updated etc. to start with a simple "hello world" proof-of-concept application.

Labels (1)
0 Kudos
1 Solution
78 Views
CompilerGuru
NXP Employee
NXP Employee

No, I don't see a flaw. All interupts are directed to the S12X out of reset, so they have to be explicitely redirected to the XGATE, if the XGATE should handle them. The XGATE is completely an optional co-processor.

The S12X can do anything the XGATE can, just not as fast, and the two cores also can separate their tasks.


 

Daniel

View solution in original post

0 Kudos
4 Replies
78 Views
jacwit
Contributor I

Daniel, thanks for your assistance. In my case where I will not use the Xgate initially are there any precautions I need to take in order to keep Xgate quiet/shutoff in the unlikely event the code goes off into the weeds?

 

0 Kudos
78 Views
jacwit
Contributor I

Thanks for your response. My comments are long in hopes that both my findings and responses will help someone in the future. Please correct any incorrect statements.

 

I did see that I have to enable Xgate when I set up the initial project. Code intended to run on the XGate has its own special file extension (.cxgate) whereas code intended for the processor maintains the standard extension (.c). You cannot call a function written for the Xgate from the S12XA and vice-versa as the code is not compatible between processors. There are a few app notes describing how to exchange data between the two processors.

 

If I understand you correctly, I can move my code over with minimal effort to start. The peripherial / memory mapping is not direct but I think those fix-ups are relatively quick. The peripherials are not exclusively mapped to the Xgate processor rather I have a choice between which processor (Xgate or S12XA) manipulates SCI, SPI, I2C, etc. depending upon my implementation.

 

I did see somewhere in the high-level documentation that I control which processor handles the peripherial interrupt(s). Again, I want to reiterate that am interested in just getting my exisiting application moved over quickly and then focus on using Xgate making the changes one peripherial at a time (i.e, SPI, SCI, I2C).

 

I think my approach, in general, is good especially if anyone feels a bit intimidated about Xgate in the beginning. This is true in whether migrating processors or coding from scratch. Do you see any flaw in this reasoning?

 

 

 

 

 

 

 

0 Kudos
79 Views
CompilerGuru
NXP Employee
NXP Employee

No, I don't see a flaw. All interupts are directed to the S12X out of reset, so they have to be explicitely redirected to the XGATE, if the XGATE should handle them. The XGATE is completely an optional co-processor.

The S12X can do anything the XGATE can, just not as fast, and the two cores also can separate their tasks.


 

Daniel

View solution in original post

0 Kudos
78 Views
CompilerGuru
NXP Employee
NXP Employee

The XGATE has to be explicitely enabled in order to run, therefore the disabling is done implicitely by not enaling it.

 

Daniel

0 Kudos