XMC1100 external interrupt timing problems

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Not applicable
Hi everybody!

I have some problems with the XMC1100 ( XMC1100-T038F0064 AA on the XMC1100 Boot Kit) and its external interrupts and timers...

The basic problem setup: I have an external signal which creates a rising edge (jump from 0 to 5V) at specific moments. I want to detect the rising edge, wait for an exact time period (between 3-60 µs) and send out a SSC data packet immediately after this time period.

I am using the ERU to generate an interrupt service routine for the rising edge, inside the SR I start one of the CCU timer slices with the wanted period value and inside the timer period SR I write the data packet into the transmit buffer of the SSC.

My problem is now, that the duration between the rising edge on the external input and the first data bit from the SSC on the TX line varies up to 0.7 µs, which is not acceptable for my application.... I could deal with constant delays but I cannot deal with this high duration differences between 2 successive rising edges...

The project worked fine with a XC164 and its "fast external interrupts", so I don't think that there is any problem with the external hardware (external rising edges are very stable)

I have also tried to use the CCU for creating the external interrupt SR instead of the ERU and have also tried to use the System Ticker as Timer instead of the CU timer... but the jitter remains (nearly) the same...

After some error searching with debug pins I can say: Approx. half of the jitter occurs between the external rising edge and entering the ERU interrupt SR and the other half occurs between starting the timer and writing to the SSC transmit buffer.

You can find my basic code in the attachment...

Does anybody has an idea what I am doing wrong or has an idea who to do it better??? Or do I have to accept this jitter (although I am very surprised that such a basic algorithm can vary up to 0.7 µs)

best Robert

P.s. I really want to do this with a XMC1100 Boot kit and without Dave Apps, so please don't tell me which MC is better 🙂
0 Likes
5 Replies
chismo
Employee
Employee
First like received
Hello Robert,

The jitter could be due to the adaptive wait state generation of the Flash.
For a more deterministic timing, could you try putting the interrupt routines in the SRAM?

You just need to add the following declarations:

void IRQ_Hdlr_3(void) __attribute__ ((section (".ram_code")));
void IRQ_Hdlr_21(void) __attribute__ ((section (".ram_code")));


Regards,
Min Wei
0 Likes
Not applicable
Thanks for your idea but unfortunately it is not getting any better 😞
0 Likes
chismo
Employee
Employee
First like received
Hello Robert,

From the disassembly or listing file, are you able to see that the ISR execution occurs in SRAM (address 0x2000'xxxx)?
I am surprised that this does not improve the timing the slightest bit.

Another approach would be to optimize the resources used.
I see that you are using P2.0 as the external pin interrupt.
Would it be possible to use another pin?

The CCU4 supports an external start function via a configuration edge/level on a CCU4.INxx pin.
For example:

// Configure P0.0 rising edge as event 0 for external start
WR_REG(CCU40_CC40->INS, CCU4_CC4_INS_EV0IS_Msk, CCU4_CC4_INS_EV0IS_Pos, 2);
WR_REG(CCU40_CC40->INS, CCU4_CC4_INS_EV0EM_Msk, CCU4_CC4_INS_EV0EM_Pos, 1);
WR_REG(CCU40_CC40->CMC, CCU4_CC4_CMC_STRTS_Msk, CCU4_CC4_CMC_STRTS_Pos, 1);

This way you don't even need the ERU and can save on 1 ISR.

If it is mandatory for your application to use P2.0, I would suggest then to use the ERU to trigger directly the start of CCU4 timer via interconnects (PDOUT -> CCU4.INxx).
Similarly, we can save on 1 ISR.

Regards,
Min Wei
0 Likes
Not applicable
Thanks again for your help. I can use any pin I want for the external input signal, so I have tried to start the timer directly by the external start function (with P0.0)

I think now it is a bit better, but there is still a jitter of approx. 200-250ns between the rising edge on P0.0 and then first SSC bit, which is still way too much for my application 😞
0 Likes
chismo
Employee
Employee
First like received
Hello Robert,

To eliminate any possibility of Flash wait state generation causing the jitter, can you try to reduce the system frequency (MCLK) from 32 MHz to 8 MHz?
At 8 MHz, no Flash wait states will be generated.

The code to do that is the following:

//----CLOCK-SETUP-----------------------------------------------------------------------------------
SCU_GENERAL->PASSWD = 0x000000C0UL;
SCU_CLK->CLKCR = 0x3FF00400UL; // 8 MHz MCLK, 8 MHz PCLK
while((SCU_CLK->CLKCR)&0x40000000UL); // wait for VDDC to stabilize
SCU_GENERAL->PASSWD = 0x000000C3UL;
//--------------------------------------------------------------------------------------------------


Regards,
Min Wei
0 Likes