xgatev3 software error debugging aid available? + developer ease for xgate error handling needed - mc9s12xep100

[Xbot]

hi,

we are using mc9s12xep100 as mcu. this uses xgatev3 and from the app.note 3555, it states there that xgatev2 and xgatev3 will have a slight difference... may i know what the differences are?

also, this software erro investigation is taking much of my time. is there a better way of doing this?

thanks,

Added p/n to subject.

Message Edited by NLFSJ on 2008-04-22 06:07 AM

[HSW]

Hello Xbot,

AN3555 only applies to the XGATEV2. A similar application note for the XGATEV3 is intended, but has not been written, yet.

Since XGATEV2 and XGATEV3 are different implementations of the coprocessor design, the "observable conditions" as listed in section 4.4 of AN3555 are not exactely the same. Some of the differences are:

•  S12XE devices have an MPU, which adds a possible "software error condition" to any XGATE execution cycle.
• The XGATEV3 initializes R7 with the content of one of the XGISPxx registers. -> So XGCHPL and XGISPxx must be added to the observed registers.
• The software error behavior of the JAL an branch instructions has been slightly improved.
  

I understand that XGATE software errors are not always easy to debug. But after all this is a safety feature. Stopping the XGATE asap in case of erratic application code is considered more important than running until a well defined state at the next instruction boundary is reached, to ease debugging.

HSW

[Xbot]

Hi,

Is it possible to norrow down to the software error conditions to just the one's applicable for MPU?

[HSW]

Hello Xbot,
I guess it is.
The debug capabilities of the XGATEV3 have been improved so that the XGPC register should point you in the right direction:
-> If the MPU error occurs during a vector fetch, then the XGPC regster will contain the vector address (XGPC = XGVBR + XGCHID)
   Here you will have to check which one of the two vectors has caused the MPU violation.

-> Otherwise the XGPC register should point to the instruction which has caused the problem:
   First check whether the address in XGPG does not have execute permission.
   If it does, then XGPC will either point to a JAL or branch instruction which performs an opcode prefetch from somewhere that the MPU doesn't allow.
   Or it will point to a LDx or STx instruction and the data access is not permitted by the MPU.

I hope that helps,
HSW

Message Edited by HSW on 2008-04-22 04:38 PM

[Xbot]

Helo again,

You mean to say, XGPC have enough information to be able to determine the address of the error, the read-write violation, no-execute violation, etc...?

[HSW]

Hello Xbot,
Yes, on the XGATEV3 XGPC will show you where the problem occured.  And if you are sure that the problem was detected by the MPU then you can just iterate through the descriptors to determine the cause.

There is just one scenario that is a little bit tricky:
If a software error is triggered by a "JAL Rx"-jump to an illegal destination, then XGPC will point to the JAL instruction. And, because the JAL instruction itself is in a legal (executable) location, you will figure that the destination address must have been the problem. However, you can't tell anymore what the exact destination address would have been and which MPU descriptor detected the problem, because Rx will aready contain the return address by the time the XGATEV3 stops for the error.

Regards,
HSW

[Xbot]

thank you very much. I rest my case... I hope Xgatev3 debugging ap will be available soon.

[HSW]

I can't promise that the application note will be ready anytime soon. So, if you need help getting your error analysis function implemented, just post your questions here.
Regards,
HSW

[Xbot]

ok, very well...

can you please provide a list of all errors/faults(like error conditions) for s12 and xgate.?

thanks

[HSW]

Hello Xbot,
The differences between the XGATEV2's and the XGATEV3's software error conditions come from the different memory protection schemes. S12X devices have a RAM write protection logic. S12XE devices have a full MPU. So, the XGATEV3 may see a memory protection violations at any cycle, where as the XGATEV2 can only violate the memory protection scheme when it executes STB/W instructions.  Please have a look at the attachment for a full list of all XGATEV3 software error conditions.

But, before I end up writing the entire application note in this thread, can you give me a description of what your function is supposed to return? What Informaton are you trying to extract exaclely? And at which level of detail?

Regards,
HSW

[jsmcortina]

Digging this up from the dead...

One thing that appears unclear in the docs I have found so far.

The XGPC register is marked as readable in debug mode. Does an XGATE software error condition automatically allow this to be readable?

If not, what steps are required to access XGPC and the other useful registers for tracking down a software error. 

Does this still work if the device is secured?

thanks

James

[HSW]

Hello James,

When the XGATE stops program execution due to a software error, it does not switch to debug mode. You will need to set the XGDBG bit in the XGMCTL register manually.

When the XGDBG bit is set (debug mode) and the device is not secured, you will have read/write access to the registers of the RISC core (XGPC, XGR1, ...). You can't read or write these registers if the MCU is secured.

Regards,

HSW

[Xbot]

Hi HSW,

Thanks for the reply. I am writing a Xgate error interrupt handler function that would read the error and store this into the NVM for diagnostics purposes.

The function gets the address of the error and indicate whether it was a no-execute error or a write-protect error and so on...

thanks,

[HSW]

Hello XBot,
Wouldn't it be much easier to just dump all relevant registers into the NVM and do the error analysis later. A XGATE software error is something serious which should never occur. So, you might as well just resevere the extra bytes for your error log entries.

But anyway, if you want to analyze the problem right in the ISR, this is what you can do:

1. Check whether the error occured during a vector fetch or or while executing application code:
    XGPC != XVBR+XGCHID*4 => Problem occured during code execution (proceed with step 3.)
    XGPC == XVBR+XGCHID*4 => Problem occured during most likely during a vector fetch (proceed with step 2.)

2. Two things could have happened: The application code jumped into the vector table or a vector fetch failed. Instead of going through the hassle of analyzing both possibilities, I would just put a no-exec block on the vector table. Then you can be sure thet the problem occured during a vector fetch. Now you could try to find out which of the three vector fetch cycles went wrong:
1st V-cycle: XGPC points to read-protected or unimplemented address space.
2nd  V-cycle: XGPC+2 points to read-protected or unimplemented address space.
1st P-cycle: [XGPC] is odd or points to execute-protected or unimplemented address space.

3. Next check if XGPC points to execute-protected or unimplemented address space. If this is the case, then you know that the fetching of the opcode at [XGPC] failed. Otherwise continue with step 4.

4. If the opcode at [XGPC] is a JAL- or branch instruction, then the destination address must be either odd or point to execute-protected or unimplemented address space. Otherwise continue with step 5.

5. If the opcode at [XGPC] is a LDx- or STx instruction, then you the data access must have caused the prolem. It could have been a word access to an odd address, a MPU access violation, or the address could have been in unimplemented space.

Regards,
HSW

[Xbot]

Hi,

Im really sorry for the hassle. Anyway we need to get the feel of things so we can head out to doing applications layer.

if it is more convenient to you, you may send your reply thru my email.

xsanchez@lear.com