FlexCAN + MQX on Vybrid TWR-VF65GS10

[robsoncosta]

Hello everybody,

I'm working with TWR-VF65GS10 (SCH27442-RevG1/700-27442-RevJ) + TWR-SER2 (SCH26185-RevD/700-26185-RevB) and trying to run a FlexCAN application over the MQX 4.1.1 (on A5 core) using IAR + i-Jet.

In order to connect the FlexCAN signals at the tower, was inserted a 0 ohm resistor in R10 and R11 of TWR-VF65GS10.

Also was performed the workaround for e5295 (document VYBRID_2N02G.pdf) that lock the FlexCAN module in Freeze Mode.

The application use the new FlexCAN driver (fsl_flexcan_driver.c) to initialize the controller and try to send a data frame.

After run the application two problems were observed:

#1 - A data frame is sent only if the baud rate used it is 250Kbps or 125Kbps.

          Into this context, a wave analysis was performed and a strange behaviour was observed on the change of bit status.

          In order to exemplify this problem was sent in attached the oscilloscope images for 250Kbps and 500Kbps.

          My question is: Is this a normal behaviour???

#2 - Even when a data frame is successfully sent (using 250Kbps or 125Kbps) the command "flexcan_send" remains blocked.

          The data frame sent is confirmed by a sniffer on CAN bus.

          Performing a more detailed analysis, was observed that execution flow is blocked while it wait an event.

          This code is located into the "fsl_flexcan_driver.c" file in the "flexcan_send" routine (line 437).

          The execution flow is blocked in the following code:

           // Wait for the event

          if (_lwevent_wait_ticks(&event, 1 << mb_idx, FALSE, 0) != MQX_OK) {

                printf("\nEvent Wait for send failed");

          }

     Any suggestion???

I will appreciate any help with this situation.

Thanks.

Original Attachment has been moved to: FlexCAN_images.zip

[rendy]

Help me jiri-b36968 :smileyhappy:

[jiri-b36968]

Hi Robson,

#1 no this is not correct.

by insertion R83 and R84 CAN phy (TWR-SER2) is connected to PTB14 and PTB15 (Vybrid CAN0). Those pins are used for I2C.

Please ensure that I2C0 is not enabled in MQX configuration file and not used in the code nor on modules.

Ensure that jumpers are inserted in TWR-SER2 CAN-ISO connector 3-4 and 5-6 pins.

Signals should look like this:

TX signal rising edge have to be sharp - because of it - RX is much longer than supposed to be.

CAN Transmit 1Mb/s zoom, Channels:  1 CAN_L, 2 CAN_H, Math 2-1, 3 TXD

CAN Receive 1Mb/s zoom, Channels:  1 CAN_L, 2 CAN_H, Math 2-1, 3 RXD

#2 every massage on CAN have to be acknowledged. message is corrupted (#1) moreover some device have to be connected.

/Jiri

[robsoncosta]

Hi Jiri and Rene,

   Firstly thanks for the help!!!

   Jiri, in my case was needed to use the CAN1 interface, once my board (TWR-SER2 SCH26185-RevD)  doesn't have the CAN0 interface.

   In this context, the PTB16 (with R11) and PTB17 (with R10) are connected.

   Those pins are shared with I2C1 also.

   By this reason the I2C1 was already disabled in MQX.

   Also, both jumpers (3-4 and 5-6) was already inserted in TWR-SER2 CAN_ISO connector.

   In order to avoid any interference, all tests were performed based on a new project with the FlexCAN code only.

   After your answer, was performed another test with both I2C0 and i2C1 disabled but the signal behaviour remains the same.

Thanks,

Robson 

[jiri-b36968 · Accepted solution]

Hi Robson,

Yeah, sorry. So your trace is:  TWR-SER2 (On elevators CAN0) - R10,R11 - CAN1 (Vybrid) - but it is almost the same.

So your issue is probably caused by IOMUX setting:

please locate init_gpio.c line 483 where is:

// CAN1_RX (PTB17)

IOMUXC_RGPIO(39) = 0x103DE2;

// CAN1_RX (PTB16)

IOMUXC_RGPIO(38) = 0x103DE1;

and rewrite it to:

1. correct direction

// CAN1_TX (PTB17)

IOMUXC_RGPIO(39) = 0x1039E2;

// CAN1_RX (PTB16)

IOMUXC_RGPIO(38) = 0x1039E1;

2. correct direction with drive strength optimize

// CAN1_TX (PTB17)

IOMUXC_RGPIO(39) = 0x1000E2;

// CAN1_RX (PTB16)

IOMUXC_RGPIO(38) = 0x1000E1;

3. correct direction with RX pull ups

// CAN1_TX (PTB17)

IOMUXC_RGPIO(39) = 0x1039E2;

// CAN1_RX (PTB16)

IOMUXC_RGPIO(38) = 0x1039FD;

4. correct direction optimized with RX pull ups

// CAN1_TX (PTB17)

IOMUXC_RGPIO(39) = 0x1000E2;

// CAN1_RX (PTB16)

IOMUXC_RGPIO(38) = 0x1000FD;

/Jiri

[robsoncosta]

Hi Jiri,

   Great job...

   Thank you so much!!!

   Now the TXD FlexCAN signal shows the expected behaviour.

   The first modification suggested by you was used:

           1. correct direction

          // CAN1_TX (PTB17)

          IOMUXC_RGPIO(39) = 0x1039E2;

          // CAN1_RX (PTB16)

          IOMUXC_RGPIO(38) = 0x1039E1;

   This modify the bit[10] (Open Drain Enable Field) of IOMUXC_PTB16 and IOMUXC_PTB17 to 0 (ie. Output is CMOS).

Thanks again,

Robson Costa

[robsoncosta]

Some missed informations about images:

     CH1 - RXD signal (between the transceiver and the CPU)

     CH2 - TXD signal (between the transceiver and the CPU)

Thanks

[karina_valencia]

Hi Robson,

can you post  your question into the  vybrid space?

[karina_valencia]

Thanks.