Not applicable
Sep 11, 2018
01:33 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 11, 2018
01:33 AM
I'm facing some strange behavior when implementing timer interrupts on the XMC1100 (XMC1100T016X0064)
Using DAVE, I selected a Manchester decoder on Slice 0, and a 1 millisecond timer on slice 1.
All seemed to work ok, until I started investigating some strange behaviour.
First I discovered that the interrupt priority was not behaving as expected.
The Manchester decoder interrupt was executing at lower priority than set. It was interrupted by an low priority interrupt which I found strange.
I checked every configuration register using the debugger and all seemed correct to me. (Slice 0 was set to 0, others to higher values (lower prio))
By pure luck I discovered that setting the priority for Slice 0 to Slice 1 solved the issue.
After digging deeper I found that Slice 0 triggers the interrupt handler/vector for slice 1 (CCU40_1_IRQHandler ; Handler name for SR CCU40_1)
and vice versa Slice 1 triggers interrupt for slice 0 (CCU40_0_IRQHandler ; Handler name for SR CCU40_0)
I was puzzled. How could my application ever have worked? I checked the Errata sheet but I was unable to find any information regarding this behaviour.
Then I discovered DAVE apparently knows about this because it "compensates" by generating the following macros:
#define MANCHESTERCoder_CCU4IRQHandler IRQ_Hdlr_22, which links the Manchester decoding library (Hardcoded to slice 0) to the interrupt handler of Slice 1
and
#define TIMER1_ISR IRQ_Hdlr_21, which links slice 0 interrupt to the slice 1 handler.
Questions:
- Is this a known issue?
- If it is, why isn't it in the Errata sheet?
- If it isn't why is DAVE compensating for this?
- Why are the interrupt priorities not switched for Slice 0 and 1 in the initialization code?
Using DAVE, I selected a Manchester decoder on Slice 0, and a 1 millisecond timer on slice 1.
All seemed to work ok, until I started investigating some strange behaviour.
First I discovered that the interrupt priority was not behaving as expected.
The Manchester decoder interrupt was executing at lower priority than set. It was interrupted by an low priority interrupt which I found strange.
I checked every configuration register using the debugger and all seemed correct to me. (Slice 0 was set to 0, others to higher values (lower prio))
By pure luck I discovered that setting the priority for Slice 0 to Slice 1 solved the issue.
After digging deeper I found that Slice 0 triggers the interrupt handler/vector for slice 1 (CCU40_1_IRQHandler ; Handler name for SR CCU40_1)
and vice versa Slice 1 triggers interrupt for slice 0 (CCU40_0_IRQHandler ; Handler name for SR CCU40_0)
I was puzzled. How could my application ever have worked? I checked the Errata sheet but I was unable to find any information regarding this behaviour.
Then I discovered DAVE apparently knows about this because it "compensates" by generating the following macros:
#define MANCHESTERCoder_CCU4IRQHandler IRQ_Hdlr_22, which links the Manchester decoding library (Hardcoded to slice 0) to the interrupt handler of Slice 1
and
#define TIMER1_ISR IRQ_Hdlr_21, which links slice 0 interrupt to the slice 1 handler.
Questions:
- Is this a known issue?
- If it is, why isn't it in the Errata sheet?
- If it isn't why is DAVE compensating for this?
- Why are the interrupt priorities not switched for Slice 0 and 1 in the initialization code?
- Tags:
- IFX
2 Replies
Sep 11, 2018
05:34 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 11, 2018
05:34 AM
Hi,
I would suggest to have a look at the MANCHSTER_SW_EXAMPLE_XMC12 given for the XMC1200 Boot Kit board. Yes, it´s a microcontroller than in your case but from the application point of view it will be the same as in your case. There you have a working example that´s using Manchester decoder as in you case.
Regarding the issue that you observe...it´s possible to specify which interrupt handler do you want to use and which slice should be used. Check the figure below:
These two things are independant...slice 0 doesn´t need to be connect to interrupt handler 0 for that module. So DAVE gives you possibility to mix and match as you want and if you didn´t assign slice number and interrupt handler on your own, DAVE will take the freedom of picking these settings on it´s own and consequently generate the #define macros to make everything work together.
You may try to adapt the mentioned example to you need and play a bit with the interrupt handler setting and see how the generated code which is located under DAVE -> Generated -> MANCHESTER_SW -> manchester_sw_conf.c will change.
Best regards,
Deni
I would suggest to have a look at the MANCHSTER_SW_EXAMPLE_XMC12 given for the XMC1200 Boot Kit board. Yes, it´s a microcontroller than in your case but from the application point of view it will be the same as in your case. There you have a working example that´s using Manchester decoder as in you case.
Regarding the issue that you observe...it´s possible to specify which interrupt handler do you want to use and which slice should be used. Check the figure below:
These two things are independant...slice 0 doesn´t need to be connect to interrupt handler 0 for that module. So DAVE gives you possibility to mix and match as you want and if you didn´t assign slice number and interrupt handler on your own, DAVE will take the freedom of picking these settings on it´s own and consequently generate the #define macros to make everything work together.
You may try to adapt the mentioned example to you need and play a bit with the interrupt handler setting and see how the generated code which is located under DAVE -> Generated -> MANCHESTER_SW -> manchester_sw_conf.c will change.
Best regards,
Deni
Not applicable
Sep 11, 2018
07:48 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 11, 2018
07:48 AM
Hi,
Thanks for your reply. I failed to notice that the interrupt lines were configurable.
Most processors I've used had a fixed interrupt vector per peripheral.
I've corrected the configuration and I'm making progress now 🙂
Thanks for your reply. I failed to notice that the interrupt lines were configurable.
Most processors I've used had a fixed interrupt vector per peripheral.
I've corrected the configuration and I'm making progress now 🙂