While loops in USB ISR

[ryedwards]

While testing code I noted that if the CAN XCVR doesn't have 5V the CAN_MSR_INAK bit will never set. Therefore, the while loop in can.c:

139:	can->MCR &= ~CAN_MCR_INRQ;
140:	while ((can->MSR & CAN_MSR_INAK) != 0);

Will hang while in the USB ISR. We should probably create timeouts for these to prevent a full hang?

Might be a moot point as if the xcvr doesn't have 5V we have bigger problems. The host will still timeout on the "ip link set canX up" command.

[marckleinebudde]

What should the firmware do, if it detects a timeout? The USB stack doesn't care about the return value, so we can only time out (towards to USB host) at this point and maybe put the LED into some error flashing state...

[ryedwards]

Agree. I'm not sure. The firmware can't really do anything about a HW issue in this case. Might only be correctable if the 5V feed is switched (e.g. cannette). It's easy to debug with the ICD attached but for someone with just hardware there would be no indication of what the problem is. I like the idea of LED error indication.

Overall just trying to correct the mortal sin of a while loop in an ISR :)

[marckleinebudde]

Oh, that's inside the ISR, the timer tick IRQ is probably blocked?

[ryedwards]

Yes. You'd need to use a counter in the while loop.

[fenugrec]

a counter, or read the freerunning SysTick value ? (not via HAL_gettick since that depends on the systick ISR...)

[fenugrec]

(not a fan of that characteristic of HAL_gettick of requiring an ISR, but that's beside the point here)

[marckleinebudde]

With a normal counter it's not so easy to wait for a certain time (on different µCs). Tickless sounds interesting, I want to have the full timer resolution anyways for the timestamps :)