infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

+ Reply to Thread
Results 1 to 4 of 4

Thread: Problems with FIFO/Gateway on XMCs 4400 Multican

  1. #1
    New Member New Member Milsch is on a distinguished road
    Join Date
    Jul 2017
    Posts
    3
    Points
    32.5

    Problems with FIFO/Gateway on XMCs 4400 Multican

    Hello,

    we built up a gateway with an XMC 4400 between Can Node 0 and 1.
    Gateway is in both directions, all messages from Node 0 to Node 1 and from Node 1 to Node 0.
    Therefor we have on RX MO on Node 0 and a TX FiFo with 30 MOs on Node 1.
    Same the other way round.

    Our Code:
    Node 1 Rx MO:
    /* Message 33 Configuration - Receive */
    XMC_CAN_MO_Config(&message33_rx_n1);
    XMC_CAN_GATEWAY_InitSourceObject(&message33_rx_n1,
    ( (XMC_CAN_GATEWAY_CONFIG_t) {
    2,
    31,
    2,
    true,
    true,
    true,
    true
    }));

    Node 0 Transmit fifo
    /*Message 2 Transmit*/
    /*Base Objects*/
    XMC_CAN_MO_Config(&message2_31_tx_gw_n0);
    XMC_CAN_TXFIFO_ConfigMOBaseObject(&message2_31_tx_ gw_n0,((XMC_CAN_FIFO_CONFIG_t){2,31,2}));
    XMC_CAN_GATEWAY_InitDesObject(&message2_31_tx_gw_n 0);
    /*Slave Objects*/
    for ( i = 3; i <= 31; i++ ) {
    message2_31_tx_gw_n0.can_mo_ptr += ( CAN_MO3 - CAN_MO2);
    XMC_CAN_MO_Config(&message2_31_tx_gw_n0);
    XMC_CAN_TXFIFO_ConfigMOSlaveObject(&message2_31_tx _gw_n0,((XMC_CAN_FIFO_CONFIG_t){2,31,2}));
    XMC_CAN_GATEWAY_InitDesObject(&message2_31_tx_gw_n 0);
    }


    Gateway is working fine, if both can busses are okay.

    BUT if we have a temorary disconnection on on bus, the Gatewas/FiFo is struggeling,
    means messages are no more forwarded any more at once, but at different times.

    Example:
    On Node 0 we have periodig can message which are gatewayed to node 1.
    Everything works.
    Now we disconnect the Can bus on node 1, can bus on node 0 is still working.
    After a while we reconnect can node 1 bus.
    The effect is now, that some forwarded messages are not forwarded directly,
    but later up to 2 seconds.
    That does mean that the ordering of the messages is different on Node 1 than on Node 0.
    This is terrible for our application.
    We tried to reset the messagecounters for the Fifo, TX request flags, and any other
    flag without any final result.

    Does anyone have an Idea what to do ?

    Regards

  2. #2
    Beginner Beginner OMR will become famous soon enough
    Join Date
    Apr 2013
    Posts
    96
    Points
    77.294921875
    We also have this problem with our gateway (HW-mode). When the RX-fifo on the gateway goes full we se exactly the same symptoms. Messages are lost, delayed up to 2s or actually swapping place in the Q.

    Would be nice if someone from Infineon could chime in on this. @travis?

  3. #3
    New Member New Member Tobias L. is on a distinguished road
    Join Date
    Nov 2017
    Posts
    3
    Points
    30
    I have the same problems on a XMC 1404. After a short bus failure the gateway doesn't work correct. My workaround was to use a standard message object instead of a TX-FIFO and it works fine without any message losts. But i have a very low bus load (<10%).

  4. #4
    Beginner Beginner
    Infineon Employee
    Infineon Employee
    SunYajun is on a distinguished road
    Join Date
    Nov 2014
    Posts
    6
    Points
    88.125
    By using gateway with FIFO (RxMO an gateway source side, TxFIFO MOs an gateway destination side) two pointers must be initialized
    - pointer (defined via MOFCR register in the RxMO) for gateway feature
    - pointer (defined via MOFCR register in the TxFIFO base object )
    both pointers are working independently during CAN operation, i.e. the pointer of RxMO on the source side updates each time when CAN frame has been received, while the pointer of TxFIFO base object updates when CAN frame has been transmitted successfully on the destination CAN bus.

    here is the ‘HW gateway feature’ has been initialized. that means ‘TxRQ is set’ in the gateway destination object automatically.
    in case when the destination CAN node is disconnected or bus error/high load occurs the destination side, TxFIFO elements will be reloaded with new received CAN frames, but the pointer is not updated due to bus error. it may happen that you get an TxMO.MSGLST status but no FIFO overflow interrupt.
    when you connect the CAN destination CAN node again, a new CAN frame may be sent out before old CAN frames on the destination bus, also a corrupted transmission sequence.
    the max. configurable TxFIFO is limited due to total MSG objects (see please the data sheet or user’s manual) therefore it is to recommended to use ‘SW controlled gateway feature’ in order to avoid this problem.

    here is an example code, please try it and contact us for further information and forward your feedback
    - disable ‘automatical TxRQ set’ in the gateway source object
    XMC_CAN_GATEWAY_InitSourceObject(&message33_rx_n1,
    ( (XMC_CAN_GATEWAY_CONFIG_t) {
    2,
    31,
    2,
    true, false (true=>HW controlled gateway; false=> SW controlled gateway)
    true,
    true,
    true
    }));
    - enable RxOK interrupt for all TxFIFO message objects (base object und all slave objects: MO2..MO31) and assigned to the same interrupt line
    - in the Interrupt service routine set TxRQ
    void CAN_viSRN8(void) interrupt CAN_SRN8INT
    {
    ubBaseTxFIFOCUR= (ubyte) (CAN_HWOBJ[2].uwMOFGPRH & 0x00FF); // MO2 is the TxFIFO base, get CUR of TxFIFO

    if (CAN_HWOBJ[ubBaseTxFIFOCUR].uwMOCTRL & 0x0010) // if the TxFIFO CUR pointered MO has MSGLST==1
    CAN_HWOBJ[ubBaseTxFIFOCUR].uwMOCTRL = 0x0010; // reset MSGLST of this TxFIFO MO
    else
    CAN_HWOBJ[ubBaseTxFIFOCUR].uwMOCTRH = 0x0100; // set TxRQ in this TxFIFO MO
    }
    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.

+ Reply to Thread
Disclaimer

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.