+ Reply to Thread
Results 1 to 4 of 4

Thread: XMC4700 MULTICAN+ Problem by using DAVE 4 apps

  1. #1
    Beginner Beginner TUMstudent is on a distinguished road
    Join Date
    Jan 2017
    Location
    Munich
    Posts
    2
    Points
    55

    XMC4700 MULTICAN+ Problem by using DAVE 4 apps

    Hello,

    I have created a MUTLICAN+ program which runs smoothly in loop-back mode. If I switch off the loob-balck mode and try to send via a PCAN-View can messages to my XMC4700 Relax Kit or receive some from it, it does not work. My bus seem to be BUSHEAVY all the time. Now I am unsure whether I have something wrong in the configuration.

    In order to send messages without Loob-Balck mode, I have to connect the respective pins (here: P1.12 and P1.13) to the MULTICAN_CONFIG APP, if I understood correctly?
    Now I have created over two instances of the DIGITAL_IO APP and assigned them the two pins. Furthermore, I renamed the two instances to CAN_TX and CAN_RX.
    CAN_TX was set as Input/Output and CAN_RX as Input. Now I would nevertheless in the "HW Signal Connections" tool of the MULTICAN_CONFIG APP assign the pins as well as the interrupt.

    Now I have the problem that I can assign nothing to the transmit node (node0), as well as the receive node (node1). Only their counterparts, as seen below.

    # event_lmo_01_rxinp -----> INTERUPT_0, sr_irq
    # tx_pin_node1 -----> CAN_TX, pin
    # rx_pin_node0 -----> MULTICAN_CONFIG_0, rx_pin_node1

    This is the only configuration I could do but now it should really look more like this:

    # event_lmo_01_rxinp -----> INTERUPT_0, sr_irq
    # rx_pin_node1 -----> CAN_RX, pin
    # tx_pin_node0 -----> CAN_TX, pin

    However, these settings can not be made !?

    I hope you can help me, how I can set with DAVE 4 in the latest version the pins for my XMC4700 Relax Kit correct for CAN right?
    As already mentioned in Loop-Back mode everything works without errors!

    Best regards
    TUMstudent

  2. #2
    Advanced Advanced
    Infineon Employee
    Infineon Employee
    DRubeša will become famous soon enough
    Join Date
    Jul 2016
    Location
    München
    Posts
    193
    Points
    775.625
    Hi TUMStudent,

    so pins that you mentioned (1.12 and 1.13) are correct ones. However, you need to notice that both pins belong to the NODE1. You can see this by the XMC function given in the Table 7 CAN signals and XMC4700/XMC4800 Pin Mapping given in Board User Manual for your board (CAN.N1_TXD, CAN.N1_RXDC). This .N1 specifies that we´re using NODE1.
    OK, so what that has with you? Well, your idea with transmit node as NODE0 and receive node as NODE1 will not work. Both transmit and receive should be on the same node (NODE1) while this is how the CAN transceiver is connected to the XMC4700 core. For this reason, enable only one node and while the DAVE will figure it out by itself, double check that DAVE is using NODE1 as selected resource:
    Click image for larger version

Name:	multican_report.PNG
Views:	5
Size:	66.6 KB
ID:	2761

    I assume two DIGITAL_IO APPs are already added and set to pins 1.12 and 1.13. Don´t forget to add INTERRUPT_IO APP. Now we need to connect everything. For this we use "HW Signal Connections" tool. Connect everything as is shown on following figures:
    Click image for larger version

Name:	multican_connection.PNG
Views:	12
Size:	32.8 KB
ID:	2762

    So, interrupt event is connected with the INTERRUPT APP and it´s interrupt handler routine that will be called in case of receive event is detected. tx_pin from NODE 1 is connected to the CAN_TX DIGITAL_IO APP or more precisely to the pin 1.12. So far so good. We just miss RX_PIN. You see on top right corner this "Filter" drop-down menu. Current value is "MULTICAN_CONFIG_0". Click on it and select CAN_RX. Now connect the pin 1.13 to the input of the MULTICAN_CONFIG APP, more precisely to the rx_pin NODE 1. You will see something like this:
    Click image for larger version

Name:	rx_connection.PNG
Views:	7
Size:	21.8 KB
ID:	2763

    That should be it. Both pins are connected to NODE 1 in the logical sense.

    Let me know how it went for you.

    Best regards,
    Deni

    P.S. There is much simpler way of doing this and that is by using CAN_NODE APP instead of MULTICAN_CONFIG APP I don´t know is it mandatory for you to use MULTICAN_CONFIG APP but you can also check CAN_NODE APP. What is the difference you may wonder: while MULTICAN_CONFIG is more powerful with more functions, it´s also more complicated. CAN_NODE would immediately know which pins it can use and it would offer you those pins from the beginning so you wouldn´t need to use DIGITAL_IO APPs. Take a look by yourself
    Last edited by DRubeša; Jan 27th, 2017 at 10:25 AM. Reason: Typos
    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
    Beginner Beginner TUMstudent is on a distinguished road
    Join Date
    Jan 2017
    Location
    Munich
    Posts
    2
    Points
    55
    Hello Deni,

    Now it works fine! >> Thank you for your help! <<

    Best regards
    TUMstudent

    PS: I using the MULTICAN_CONFIG APP because I may have to implement two FIFO (Tx and Rx) lists later and have a high CAN data rate. Also it could be possible that i have to use the gateway functionatity to communicate from one CAN-Bus to an other.

  4. #4
    Advanced Advanced
    Infineon Employee
    Infineon Employee
    DRubeša will become famous soon enough
    Join Date
    Jul 2016
    Location
    München
    Posts
    193
    Points
    775.625
    Hi TUMStudent,

    Let´s take a look for a second the code of the "XMC_CAN_MO_UpdateData" function:
    Code:
    XMC_CAN_STATUS_t XMC_CAN_MO_UpdateData(const XMC_CAN_MO_t *const can_mo)
    {
      XMC_CAN_STATUS_t error = XMC_CAN_STATUS_MO_NOT_ACCEPTABLE;
      /* Check whether message object is transmit message object */
      if (can_mo->can_mo_type == XMC_CAN_MO_TYPE_TRANSMSGOBJ)
      {
        can_mo->can_mo_ptr->MOCTR = CAN_MO_MOCTR_RESMSGVAL_Msk;
        /* Configure data length */
        can_mo->can_mo_ptr->MOFCR = ((can_mo->can_mo_ptr->MOFCR) & ~(uint32_t)(CAN_MO_MOFCR_DLC_Msk)) |
                                    (((uint32_t) can_mo->can_data_length << CAN_MO_MOFCR_DLC_Pos) & (uint32_t)CAN_MO_MOFCR_DLC_Msk);
        /* Configure Data registers*/
        can_mo->can_mo_ptr->MODATAL = can_mo->can_data[0];
        can_mo->can_mo_ptr->MODATAH = can_mo->can_data[1];
        /* Reset RTSEL and Set MSGVAL ,TXEN0 and TXEN1 bits */
        can_mo->can_mo_ptr->MOCTR = (CAN_MO_MOCTR_SETNEWDAT_Msk| CAN_MO_MOCTR_SETMSGVAL_Msk |CAN_MO_MOCTR_RESRTSEL_Msk);
        error = XMC_CAN_STATUS_SUCCESS;
      }
      else
      {
        error = XMC_CAN_STATUS_MO_NOT_ACCEPTABLE;
      }
      return error;
    }
    As you can see, error code output depends only on one "if" statement and that is if the current message object is transmitting or receiving one. Apparently, in your case it assumes it´s receiving one. So, why is that?

    The problem is that in your code you pass through all function calls TX_NODE_NUMBER as an argument. However, all of these functions expect pointer to the message object and this number should just indicated to which message object the pointer refers to. So, message object not CAN node. Due to the fact that TX_NODE_NUMBER = 1, I´m pretty sure that you defined message object 1 as a receiving message object and now the function assumes OK, I´m given pointer to message object 1 which is receiving one and hmmm...I cannot update data of receiving message object so return error code "XMC_CAN_STATUS_MO_NOT_ACCEPTABLE".
    Just add additional defines like TX_MO and RX_MO, make sure they are DIFFERENT and they are equal to values you set in MULTICAN_CONFIG APP and replace the the TX_NODE_NUMBER with TX_MO in your code. That should be it

    Mahlzeit
    Deni

    P.S hahaha, I see you removed your post before I wrote an answer...OK, I´m happy it worked for you but I will leave my post here for maybe future issues.
    Last edited by DRubeša; Jan 30th, 2017 at 03:40 AM.
    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

Tags for this 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.