fopen("gpio:read") disables USB device functionality

[Fabi]

My application is based on usb/device/examples/cdc/virtual_com. When I call

fopen ( "gpio:read", (char_ptr)&gpio_int ); with

GPIO_PIN_STRUCT gpio_int[] = { BSP_SW1 | GPIO_PIN_IRQ_FALLING | GPIO_PIN_IRQ_RISING, GPIO_LIST_END };

the usb cdc communication is breaking off.

The behavior is similar as reported by ARQuattr, see https://community.freescale.com/message/89394#89394

I can exclude RAM / stack space as cause.

The usb cdc task is initialized with

{ CDC_TASK,   cdc_task,     2*3000L,  7L,       "CDC",    MQX_AUTO_START_TASK,  0,      0         },

and the task calling the fopen is configured with value 8L for priority.

Can I use gpio:read together with usb cdc device? Should I use low level ISR for GPIO interrupt handling instead of gpio:read?

[timias · Accepted solution]

I am not sure the exact reason why your CDC driver hangs up, but I do know that the CDC driver requires constant servicing, especially during the first few seconds after connection. Is it possible that one of your higher priority tasks is starving the CDC_TASK? The higher priority tasks need to sleep or block every few msec or the CDC driver will not function properly.

[Fabi]

Indeed, too many interrupts from gpio-pin were the cause. This is, if CDC works for long time and gpio:read will be opened (i.e. after delay of some minutes), too. Remark: I defined BSP_SW1 to a pin not having pull-up or pull-down.

I've also migrated to lwgpio, because it seems to need less cpu-power (but I'm not sure). However, lwgpio is fully undocumended in mqxug.pdf and mqxrm.pdf, so I haven't known it before.

So, thank you very much for your hints.

[c0170]

Hello fabi,

I wonder why you are using posix driver gpio, when there's available lwgpio.

I would test it with lwgpio and report back to us what's the result.

Regards,

MartinK