topic Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core in S12 / MagniV Microcontrollers

XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

gnaws — Thu, 15 May 2014 15:40:59 GMT

Hallo,

I've been playing with the HCS12SXE XGATEv3 for a while now.

Currently, I'm facing this odd issue, where the XGATE code seems to run fine: I've set up a GPIO pin toggle to check and see if the XGATE ISR is entered and executed correctly, and on the scope I see the GPIO pin toggling fine.

However, if I place a breakpoint at any part of the XGATE ISR, the XGATE raises an access violation interrupt request (non-maskable) to the HCS12XE core and halts code execution.

The original codebase uses Processor Expert. XGATE capabilities are now being added in.

Any ideas, on what could be possibly happening? Everything else checks out - XGATE vector table is correctly set, memory sections and code/data is aligned correctly on even boundaries.

Thanks in advance.

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

HSW — Fri, 16 May 2014 13:12:51 GMT

It sounds like you've configured the S12XDBG module to trigger an SWI interrupt whenever a XGATE breakpoint occurs. So you could check the following:

Is your vector table mapped in the correct location?
Does you SWI interrupt vector point to the correct ISR.
Did you configure the descriptors in the S12XMPU to grant access permission to the vector table and the SWI ISR.

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

gnaws — Fri, 16 May 2014 13:50:25 GMT

Heya HSW,

I've checked the vector table and the SWI ISR vector, they look good.

The MPU descriptors are configured by Processor Expert, and essentially the MPU should be disabled, from what I can tell. I'll have a closer look at those.

I've also worked through the application note here: http://www.freescale.com/files/microcontrollers/doc/app_note/AN3555.pdf, but I've not been able to detect the root cause of the error yet.

Bit more background detail: I have a standalone project, that essentially just exercises the XGATE. This works fine with breakpoints, stepping through the XGATE core etc. But integrating pieces of the code from the standalone project into the existing codebase has proved surprisingly trickly so far....

Anything else I could be missing out?

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

HSW — Fri, 16 May 2014 15:00:01 GMT

Hello Fahnder,

The access error interrupt is triggered by the MPU, you shouldn't see it if the MPU was disabled. The MPU captures the address of the faulty access in the MPUASTAT register. Does this give you a hint for the cause of the problem?

The details of application note AN3555 only apply to the XGATEV2. The listed causes of a XGATE software error are the same for the XGATEV3, but the "observable conditions" are different.

But if I understood you correctly, you don't see a XGATE software error at the moment, right? The XGATE stops at a breakpoint and enters debug mode, while the CPU handles an non-maskable access error interrupt for an unknown reason.

One more thing you could check for is the stack. Is the stack pointer set to the correct RAM location?

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

gnaws — Fri, 16 May 2014 17:18:19 GMT

I'm actually not sure if the XGATE stops and enters debug mode.

I can see that:

XGATE:

XGMCTL = 0x00C3

XGSPSEL = 0x0

HCS12XE:

MPUFLG = 0x0

MPUSTAT0/1/2 = 0x0

I can see is that control is passed to the HCS12XE core in a breakpoint in the routine "Cpu_ivVxsei".

In the CPU vector table, the corresponding entry is:

/* ISR name No. Address Pri XGATE Name Description */

&Cpu_ivVxsei, /* 0x0B 0xFF16 - no ivVxsei unused by PE */

I should clarify the terminology I've used:

The manual 'MC9S12XE-Family Reference Manual Rev. 1.25', section 6.4.6 has a Table 6-2. "Exception Vector Map and Priority" (page 274).

From referring the table, I notice this particular interrupt/exception being triggered - and I think this is in fact colloquially referred to as the "XGATE software error vector":

(Vector base + 0x0016): XGATE Access violation interrupt request

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

HSW — Fri, 16 May 2014 17:45:00 GMT

Fahnder,

In this case, XGATE Software error has occurred and the CPU is executing the non-maskable interrupt, as it is supposed to. What you"ll need to do next is to enter debug mode by writing 0x2020 to the XGMCTL register. Then you are able to read the RISC core's registers.

If you post a dump of the XGATE's register space and of the memory section which the PC points to, I'll help find the cause of the software error.

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

gnaws — Fri, 16 May 2014 19:10:22 GMT

HSW,

Here's the information:

- XGATE register space:

Dropbox - Screenshot 2014-05-16 14.00.52.png

The XGATE PC points to 0x0000 (it seems to stay there when the XGATE is inactive, but maybe this is not correct behaviour).

Is there a better way for me to post the memory dumps?

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

HSW — Fri, 16 May 2014 19:38:42 GMT

Hello Fahnder,

A XGATE SWT0 interrupt request has been captured by the XGATE (XGCHID=0x39), but no interrupt vector has been fetched (XGPC=0x0000, XGR1=0x0000). So you should have a look at the vector table. Since XGVBR is set to 0x07DC, the interrupt vector should be at 0x07DC+4*0x39=0x8C0 (or 0x7808C0 global). What do you see at this address?

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

gnaws — Mon, 19 May 2014 14:28:05 GMT

Morning HSW,

I think you're onto something here, but I don't quite understand what's going on.

I see 0xCAFE at address 0xF88C0: Dropbox - Screenshot 2014-05-19 09.17.36.png

Now, when I look at my map file, and it says:

Name Addr hSize dSize Ref Section RLIB

XGATE_VectorTable E08800 1C4 452 1 XGATE_VECTORS

I look at address 0xE08800 in the memory browser, and I see the XGATE vector table there:Dropbox - Screenshot 2014-05-19 09.25.56.png

The lines of code related to setting up XGVBR are:

#define XGATE_VECTOR_OFFSET 9

/* the first elements are unused and need not to be allocated (to save space) */

XGVBR= (unsigned int)(void*__far)(XGATE_VectorTable - XGATE_VECTOR_OFFSET);

What am I doing wrong?

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

HSW — Mon, 19 May 2014 15:55:36 GMT

Hello Fahnder,

You'll need to be careful not to mix up the 3 memory maps of the S12XE family. These are:

The global memory map (typically indicated by the suffix 'G). This is a 23-bit linear address space.
The CPU's local memory map (typically indicated by the suffix 'L). This is a combination of the CPU's 16-bit address space prepended with the value of the associated page register (PPAGE, RPAGE, or EPAGE)
The XGATE's local memory map (typically indicated by the suffix 'X). This is the 16-bit address space seen by the XGATE.

Your program maps the XGATE's vector table to the start of the flash space at address 78_0800'G, E0_8800'L, and 0800'X. The XGVBR register is set to 07DC'X (= 0800'x - 9*4) because the first 9 vectors are never used.

The XGATE SWT0 vector is located at address 78_08C0'G, E0_88C0'L, and 08C0'X. Your screenshot shows that it contains the address FBF6'X. This translates to 0F_FBF6'G or 00_3BF6'L. This points into the RAM space. Do you have any valid code in there?

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

gnaws — Mon, 19 May 2014 16:11:55 GMT

HSW,

You're right, I got confused between the three different types of memory maps.

As you said, the XGATE SWT0 vector is located at address 78_08C0'G, E0_88C0'L, and 08C0'X. The screenshot in the previous reply shows it contains the address FBF6'X.

However, this (FBF6'X) translates to 7BF6'L or FFBF6'G, if I am not mistaken.

I have my XGATE software trigger handler located at 7BF6'L: Dropbox - Screenshot 2014-05-19 11.09.51.png

Does this sound correct?

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

HSW — Mon, 19 May 2014 18:33:31 GMT

Hello Fahnder,

No, FBF6'X is located in RAM. Translated to the CPU's local address space, the ISR would need to start at 3BF6'L.

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

gnaws — Mon, 19 May 2014 18:57:14 GMT

HSW,

I used the address mapping utility "hcs12xadrmap.exe" located in "C:\Program Files (x86)\Freescale\CWS12v5.1\Prog\". The utility shows me that the global address corresponding to FBF6'X should be 7BF6'L.

Dropbox - Screenshot 2014-05-19 13.52.47.png

Am I using it incorrectly?

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

HSW — Mon, 19 May 2014 19:18:18 GMT

Hello Fahnder,

I forgot about this mapping option. If you set the ROMHM and RAMHM bit in the MMCCTL1 register (0013'L), the RAM is mapped to the address range 2000'L - 7FFF'L. What is the content of the MMCCTL1 register in your application?

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

gnaws — Mon, 19 May 2014 19:28:13 GMT

HSW,

MMCTL1 = 0x1B in my application.

The range 0x4000 to 0x7FFF is set up as non-paged RAM for me.

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

HSW — Mon, 19 May 2014 19:53:36 GMT

Hello Fahnder,

Your vector map and ISR seem to be set up correctly. When you took the screenshot after entering debug mode, while still in error state (Dropbox - Screenshot 2014-05-16 14.00.52.png), are you sure the IDE was showing the correct register content? Is it possible, that XGPC as well as XGR1-XGR7 just had not been refreshed after you set XGDBG?

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

gnaws — Mon, 19 May 2014 20:13:18 GMT

HSW,

This is the sequence of steps I followed just now:

I halted execution of code,
I placed a breakpoint in the XGATE SWT0 ISR,
I resumed code execution,
When I saw the code has halted execution, and was trapped at the breakpoint in "Cpu_ivVxsei", I clicked refresh on the "MCURegisters" component.
Then I entered 0x2020 into the XGMCTL register, using the "Memory" component.
I looked at the "MCURegisters" component. I noticed that none of the registers have changed value, except for XGMCTL.
Here's a screenshot I took at the end of the process: Dropbox - Screenshot 2014-05-19 15.11.50.png

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

HSW — Mon, 19 May 2014 21:06:50 GMT

Hello Fahnder,

What happens when you start the SWT0 thread manually in debug mode?

Enter debug mode (0x2020 -> XGMCTL)
Make sure XGSWEF is cleared (0x0202 -> XGMCTL)
Make sure no thread is active (0x00 -> XGCHID, 0x00 -> XGCHID)
Start the SWT0 thread manually (0x39 -> XGCHID)
Step through the ISR (0x1010 -> XGMCTL, 0x1010 -> XGMCTL, 0x1010 -> XGMCTL, ....)

After which step do you see the software error?

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

gnaws — Tue, 20 May 2014 14:42:21 GMT

Morning HSW,

I did the following sequence of events:

Opened the XGATE registers in the "memory" component and set the component for word-display
Entered debug mode ( 0x2020 -> XGMCTL)
Cleared XGSWEF (0x0202 -> XGCMTL)
No thread active (0x00 ->XGCHID)
Placed a breakpoint in the XGATE SWT0 ISR
Started SWT0 manually (0x39->XGCHID)
Stepped through the XGATE SWT0 ISR by selecting the XGATE source code component, and hitting F11 to step through the code (did not understand this: (0x1010 -> XGMCTL, 0x1010 -> XGMCTL, 0x1010 -> XGMCTL, ....))
I saw that the XGATE SWT0 ISR successfully executes (saw a GPIO line set high at the beginning of the ISR, and then set low at the end of the ISR, two counters incremented, etc).
I repeated step 6-7 a few times and observed everything working as expected.

Then I let the code 'free run' and immediately saw the XGATE software error triggered (i.e. code has halted execution, and was trapped at the breakpoint in "Cpu_ivVxsei").

To reiterate, this only appears to happen when a breakpoint is placed in the XGATE SWT0 ISR.

What else could I try?

Re: XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

HSW — Tue, 20 May 2014 16:21:23 GMT

Hello Fahnder,

I think it's time to use the S12XE's trace buffer. Can you do a trace of the XGATE's program counter in "Pure PC" mode?