Colibri iMX7D flexcan receive not working

I have a Colibri iMX7D module on an Aster eval board. I have an external CAN transceiver connected to another CAN device. I am using pins 90 & 92 for Rx and Tx and am configuring these in my application.

The Flexcan appears to be configured correctly with these pins because on the 'scope I can see that messages from the external device are being acknowledged by the Colibri. I can also see that when I transmit a message, it appears on the 'scope and is acknowledged by my external device.

The problem is that when I call either of the following,

can.Can_Read(hCAN, ptr) != 0
can_imx7.Imx7Can_Read(hCAN, ptr) != 0

the result is always 0 and nothing is received.

I have also noticed that when sending a message, although I can see it on the 'scope and it is acknowledged, the call

can.Can_Write(hCAN, ptr)

always returns 0.

I have attached my test project which is an adaption of your demo project.

Another thing I noticed is that in TdxAllLibraries.cs, the structure of the tCANMsg may not be correct.

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto) ]
	public struct tCanMsg
	    public UInt32 id;                                          ///< ID for CAN Bus Message Buffer (11 or 29bits used)
	    public UInt32 canMsgFlags;                                 ///< message specific flags.Currently only 2 bits are used:\n * @ref IDE "CanMsgFlags_IDE"\n * @ref RTR "CanMsgFlags_RTR" (read only)
	    public UInt32 dataLen;                                     ///< Message Data Length (0...8). This matches the DLC field of a CAN message.
    [MarshalAs(UnmanagedType.ByValArray, SizeConst = 8)]      
	    public char[] data;                                        ///< Message Data (0...8 bytes used). This matches the data field of a CAN message.

Shouldn’t the public char[] data at the end actually be public byte[]data? chars are a 16-bit representation in c#/.net.

Dear @dnicholls

Thank you for the detailed report.

At Toradex we rarely use C# except for writing the kind of interfaces for the library, so we don’t have too much experience.
Most of the library testing is done with C applications only - this explains why we didn’t find this problem so far.

Your error reports and suggestions for fixing seem to be very reasonable to me. It will take me some days before I will find time to do any tests on this.

To not be blocked I recommend to do the modifications in your local copy of the library. As the .NET interface part is in source code, it will directly affect your application.

Regards, Andy

I’ve now managed to test this with a C application adapted from the demo in the toradexcelibraries_2.3-20181011 and I am getting the same results as in my C# application. So the problem seems to be either in your CAN driver or in the way I have used it. I have attached my adapted project.

link text

Dear @dnicholls,

Thank you for your patience and efforts to report the bug.

Could you please enable debug message and capture the messages during the CAN transfer and let us know if it prints any messages.

Could you confirm that CAN message transmission is successful?

Just I checked the code, implementation seems to be proper. FlexCAN APIs returns 0 if there are any errors like CAN_ERR_TRANSFER_TIMEOUT or CAN_ERR_INSUFFICIENT_SPACE or CAN_ERR_TX_OVERFLOW or other errors detected by CAN controller.

Please let us know if you are seeing message transfer successful but FlexCAN APIs still returns the wrong value.

Hi @raja.tx

I have enabled debug and in any case of CAN transmit or recieve I see no errors. The debug output is:

Toradex Bootloader 1.3b2 for iMX7 Built Jul 31 2019
Reset cause: Power-up sequence
Colibri iMX7D 512MB 1.1D Serial: 06414151
RAM             :512 MB
NAND            :512 MB

Press [SPACE] to enter Bootloader Menu

Initiating image launch in 0 seconds.
System ready!
Preparing for download...
Loading OS Image
OEMLaunch: 0x80180000

Toradex Windows CE 8.0 1.3b2 for iMX7 Built Aug  1 2019
SMP support enabled
CPU0 started
CPU1 started
Loading FlashDisk...
Loading NAND...
Done Loading NAND (16 ms)
Done Loading FlashDisk (20 ms)
Loading PXP...
Done Loading PXP (1 ms)
Loading NTLMSSP_SVC...
Done Loading NTLMSSP_SVC (0 ms)
Loading SIP...
Done Loading SIP (7 ms)
Loading ccfgsvc...
Done Loading ccfgsvc (0 ms)
Loading SmartCard...
Done Loading SmartCard (0 ms)
Loading WAPIMAN...
Done Loading WAPIMAN (1 ms)
Loading TAPI...
Done Loading TAPI (0 ms)
Loading SDBusDriver...
Done Loading SDBusDriver (1 ms)
Loading ALPCD...
Done Loading ALPCD (0 ms)
Loading I2C4...
Done Loading I2C4 (52 ms)
Loading I2C1...
Done Loading I2C1 (97 ms)
Loading COM1...
Port is used for OS debug!
Failed(0) Loading COM1 (1 ms)
Loading Audio...
Done Loading Audio (89 ms)
Loading COM3...
Done Loading COM3 (6 ms)
Loading COM2...
Done Loading COM2 (3 ms)
Loading CredSvc...
Done Loading CredSvc (44 ms)
Loading USB_OTG2...
Done Loading USB_OTG2 (285 ms)
Loading NDIS...
Loading ENET1...
Ethernet: Disconnected
Done ENET1
Done Loading NDIS (86 ms)
Loading USBOTG...
Done Loading USBOTG (145 ms)
Loading SD Card...
Done Loading SD Card (324 ms)
Loading AFD...
Done Loading AFD (144 ms)
Loading Ws2Serv...
Done Loading Ws2Serv (0 ms)
Loading NDISUIO...
Done Loading NDISUIO (2 ms)
Loading PPP...
Done Loading PPP (1 ms)
Loading Autoras...
Done Loading Autoras (3 ms)
Loading Ethman...
Done Loading Ethman (0 ms)
Loading NdisPower...
Done Loading NdisPower (0 ms)
Loading EAP3SVC...
Done Loading EAP3SVC (2 ms)
Loading NSIPROXY...
Done Loading NSIPROXY (0 ms)
Loading NSISVC...
Done Loading NSISVC (1 ms)
Loading EAP3SVC...
Done Loading EAP3SVC (0 ms)
Loading CmService...
Done Loading CmService (143 ms)
Loading Display driver...
Invalid Bpp value used. must be 16, 18 or 24.
Done Display driver
Loading Touch...
Done Touch
SoftRTC disabled
+OEMSetRealTime(2006/1/1 12:14:38.777)
RTC Time restored (01.00.2000 00:00:68)
Loading NETUI...
Ethernet: Connected at:  100Mbps full duplex
Debugger IP Address:
+OEMSetRealTime(2006/1/1 12:14:47.990)
+OEMSetRealTime(2006/1/1 12:14:48.174)
+OEMSetRealTime(2020/3/5 14:22:43.000)
RTC Time set (05.03.2020 14:22:43)
Exception 'Raised Exception' (0x406d1388): Thread-Id=05a0002a(pth=b10b8000), Proc-Id=059c0026(pprc=b10ae8f0) 'msvsmon.exe', VM-active=059c0026(pprc=b10ae8f0) 'msvsmon.exe'
PC=4004f7bb(coredll.dll+0x0003f7bb) RA=801a1a1f(kernel.dll+0x00006a1f) SP=00b8fdb8, BVA=41a918bc

I can confirm that transmit is successful, returning 1 and I can see the data on my CAN analyser.

For recieve, it just times out, the return from Can_Read(hCan, &canBuf) is 0.

I have modified the recieve part to add a timer:

	DWORD start;

	// Configure timeout to 5 sec, by default it is set to 1 sec
    Can_SetConfigInt(hCan, L"Timeout", 5000, StoreVolatile);    // optional

	// 4. Use CAN
    canBuf.dataLen = 8;
	// Record start time
	start = GetTickCount();
	printf("\nStart Time: %dms", start);
	rxRes = Can_Read(hCan, &canBuf);

	//Record duration
	start = GetTickCount() - start;
	printf("\nCAN Recieve Result: 0x%x  Time taken: %dms", rxRes, start);

So I can see from this that it is taking 5002ms.

So although the response of 0 is correct for a timeout, why is it timing out and not getting the data that has been sent from my CAN analyser?

I am confident that our hardware is correct as I have built my own CAN driver by using MapMem to access the FlexCAN module of the iMX7. With this I have correct operation.

Dear @dnicholls,

Any chance, Do you have our Colibri Evaluation board? I quickly tested iMX7D with Colibri Eval board, the CAN interface is working flawlessly.

Hence it seems we need to verify our HW and SW thoroughly.
Is it a 120-ohm termination resistor placed?
If possible, could you go through this documentation and let us know your setup is similar
Could you confirm SODIMM_90 and 92 not connected to any other place and it is connected to CAN transceiver chip only?
Maybe could you draw a connection diagram on the paper from IMX7D module to till the PC? it would trigger a point to find the issue. The timeout can occur due to hardware connection problem or software configuration problem. Let us first verify the hardware connection is perfect since the default CAN_Demo application works I don’t expect the software configuration problem.

Hope we will found out the issue soon!