infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

+ Reply to Thread
Results 1 to 3 of 3

Thread: XMC1100 CCU4 Slice 0 and 1 interrupts switched?

  1. #1
    New Member New Member Fab is on a distinguished road
    Join Date
    Sep 2018

    XMC1100 CCU4 Slice 0 and 1 interrupts switched?

    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
    #define TIMER1_ISR IRQ_Hdlr_21, which links slice 0 interrupt to the slice 1 handler.

    - 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?

  2. #2
    Advanced Advanced
    Infineon Employee
    Infineon Employee
    DRubeša will become famous soon enough
    Join Date
    Jul 2016

    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´s possible to specify which interrupt handler do you want to use and which slice should be used. Check the figure below:

    Click image for larger version

Name:	nvicDecoder.PNG
Views:	0
Size:	44.2 KB
ID:	3609

    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,
    The views expressed here are my personal opinions, have not been reviewed or authorized by Infineon and do not necessarily represent the views of Infineon.

  3. #3
    New Member New Member Fab is on a distinguished road
    Join Date
    Sep 2018

    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

+ Reply to Thread

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.

Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.