FlexCAN interrupt not executed

Technical Support
, , , ,
1

Hello everyone,

When trying to run the flexcan_network demo code, the interrupt handler BOARD_FLEXCAN_HANDLER is not called when trying to send a message. I suspect that something is going wrong with the sending part.

I’m using FlexCAN2 with the following pin muxing: case CAN2_BASE: // CAN2_TX SODIMM 94 IOMUXC_SW_MUX - Pastebin.com.
However when printing out the value of IOMUXC_SW_MUX_CTL_PAD_I2C3_SCL it returns a 5, which is for ALT5_GPIO4_IO13, instead of the 2, which is for ALT2_FLEXCAN2_TX, that it is supposed to return.

Could it be that the pin muxing is overwritten after it is set in pin_mux.h and that this creates issues with the interrupts for flexcan2?

2

If possible i’d still like an answer on this question, as i can’t seem to figure out why this interrupt is not happening.

3

Dear @Rjm

I have the feeling that the Linux kernel overwrites your pinmuxing. Can you try to add something like follows to imx7d-colibri-emmc-aster.dts:

&pinctrl_gpio2{
	fsl,pins = <
		MX7D_PAD_SD1_CD_B__GPIO5_IO0		0x74 /* SODIMM 69 */
		MX7D_PAD_I2C4_SDA__GPIO4_IO15		0x14 /* SODIMM 75 */
		MX7D_PAD_ECSPI1_MISO__GPIO4_IO18	0x14 /* SODIMM 79 */
		MX7D_PAD_I2C3_SCL__GPIO4_IO12		0x14 /* SODIMM 81 */
		MX7D_PAD_ECSPI2_MISO__GPIO4_IO22	0x14 /* SODIMM 85 */
		MX7D_PAD_ECSPI1_SS0__GPIO4_IO19		0x14 /* SODIMM 97 */
		MX7D_PAD_ECSPI1_SCLK__GPIO4_IO16	0x14 /* SODIMM 101 */
		MX7D_PAD_ECSPI1_MOSI__GPIO4_IO17	0x14 /* SODIMM 103 */
		MX7D_PAD_SD2_RESET_B__GPIO5_IO11	0x14 /* SODIMM 98 */
	>;
};

Normally this two lines in imx7-colibri.dtsi change the pin configuration:

MX7D_PAD_I2C3_SDA__GPIO4_IO13		0x14 /* SODIMM 94 */
MX7D_PAD_I2C4_SCL__GPIO4_IO14		0x14 /* SODIMM 96 */

After that you have to recompile the dtb and copy it to the target. For more information take a look here:

Also make sure that you chose the imx7d-colibri-emmc-aster.dtb in u-boot if not already done:

setenv fdt_file imx7d-colibri-emmc-aster.dtb
saveenv

Regards,
Stefan

4

Hello Stefan,

Thanks for the response!

I created a secondary dts file, imx7d-colibri-emmc-aster2.dts with the changes you provided in your post. I also changed the environment variable, as this was not done yet. It seems as if the pin muxing is correct now, i’m getting the correct register values!

However, for some reason the interrupt is still not working. The IFLAG bit for the TXMsgbuffer, in my case 8, is not being set either. The IMASK1 bits are set correctly however.

Do you have any idea what might cause this?

Regards,

Rjm

5

Your pastebin is not valid (anymore). Can you post the muxing again?

Do you try without Linux I guess?

How does your complete setup looks like now?

6

I really suggest you build a setup we have verified here:

Get a Colibri Evaluation Board with its on-board CAN transceiver and a USB CAN adapter (we use the PCAN-USB from PEAK System.

7

Hello stefan,

The pin muxing can be found here: case CAN2_BASE: // CAN2_TX SODIMM 94 IOMUXC_ - Pastebin.com

My current setup consists of the Colibri iMX7 board in the Aster carrier board. From the Aster carrier board I connect pins X20-29 and X20-31 to the Rx and Tx of an MCP2562 CAN transceiver. I try and read out data from the CAN H and CAN L pins from this transceiver with a oscilloscope.

For software i’m using the flexcan_network example, with no changes made(except for some printf methods) and for the pin muxing the pastebin mentioned above is used. Besides that I changed the devicetree as stefan_e suggested. I am running both the m4-core and Linux simultaneously.

8

For the project i’m working on we’d prefer to have everything working on the board we have now, with an external CAN Transceiver.

Is it possible that you try to recreate my setup, mentioned in a comment above, with the same carrier board, so that we can rule out any hardware issues?

9

Hello @stefan.tx,

I was wondering if you were still investigating the issue i’m having with the interrupt, or if you tried if the same setup i have works for you.

I hope to hear from you.

10

No at this point I am not do further investigation. I tested two setups successfully and was able to communicate just fine, so software is fine. Doing further investigation is project/application specific beyond the free support.