XGATEv3 breakpoint raising an access violation interrupt request to HCS12XE core

[gnaws]

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.

[HSW]

Hello Fahnder,

The trace simply lists a sequence of XGATE PC values. It begins with FC20'X, which is the "RTS" instruction of the previous iteration of the ISR. That's where you must have started the trace and it ends with FC1A'L (LDB R2,(R0,#8)).  If the software error occurs at this point, then R1 should be 0xFC26, R2 should be "pData->counter" , at least one bit of the CCR should be set, and the PC should point to FC1A'L. I don't understand why you don't see this when you enter debug mode. Could that be a display issue of the IDE?

Let's assume the error occurs during the execution of the ISR and not during the vector fetch. There are 3 causes for a XGATE software error:

1. Illegal load or store access:
   The access goes to valid register space and you don't see an MPU access violation, so this is probably not the cause.
2. Illegal opcode fetch:
   Opcodes are fetched from valid RAM locations, so this is not causing the error either.
3. Execution of an illegal opcode:
   Would it be possible, that the CPU is writing to the XGATE's code space?

Can you verify, that the XGATE code space is still intact when the software error occurs.

[gnaws]

Morning HSW,

I had to drop this for a while and figure out a workaround, but looks like I might have some time to look into this again.

Since then, I have written ISRs for handling SCI and SPI interrupts, and everything works perfectly in the project - but I still lack being able to set breakpoints in the XGATE ISRs.

Also, I verified the XGATE code space - it is not being overwritten by the CPU.

[HSW]

Hello Fahnder,

to understand what is going on with those breakpoints it might help to look at the configuration of the DBG module. Can you dump the DBG's register space (0x0020 to 0x0027) while you're executing your program (before you run into the breakpoint)? Maybe we'll find a hint there.

[HSW]

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?

[gnaws]

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

[HSW]

Hello Fahnder,

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

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

After which step do you see the software error?

[gnaws]

Morning HSW,

I did the following sequence of events:

1. Opened the XGATE registers in the "memory" component and set the component for word-display
2. Entered debug mode ( 0x2020 -> XGMCTL)
3. Cleared XGSWEF (0x0202 -> XGCMTL)
4. No thread active (0x00 ->XGCHID)
5. Placed a breakpoint in the XGATE SWT0 ISR
6. Started SWT0 manually (0x39->XGCHID)
7. 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, ....))
8. 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).
9. 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?

[HSW]

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?

[gnaws]

I set the trigger module to trace the XGATE only, in Pure PC mode.

Just edited my previous reply, here's what I think is a "better" screenshot: https://www.dropbox.com/s/n50hjasqw48it9i/Screenshot%202014-05-20%2012.44.47.png

I can't quite understand the data yet ...

[HSW]

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?

[gnaws]

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?

[HSW]

Hello Fahnder,

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

1. The global memory map (typically indicated by the suffix 'G). This is a 23-bit linear address space.
2. 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)
3. 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?

[gnaws]

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?

[HSW]

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.

[gnaws]

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?

[HSW]

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? 

[gnaws]

HSW,

MMCTL1 = 0x1B in my application.

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

[HSW]

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.

[gnaws]

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?

[HSW]

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?