Hello folks,
I've struHello folks,
I've struggled to find the time to complete the testing with your suggestions, apologies for the tardiness.
Here are my findings:
Code: Select all
rccResetUSART2 ();
sdStart (&SD2, &config);
/* chThdSleep (MS2ST(500)); */
// Initial undesired interrupt with a TX_END occurs even without registering events
/* chEvtRegisterMaskWithFlags (chnGetEventSource (&serial),
&txComplete, EVENT_MASK (0), CHN_TRANSMISSION_END); */
In my setup the call to sdStart generates a TRANSMISSION_END interrupt, I estimated sort of by trial/error using the chThdSleep, that it takes around 100 ms from sdStart to hitting the TX_END in the ISR. That's why if I put the thread to sleep for long enough so the registration happens after that "spurious" interrupt, everything works well in sync, otherwise problem arises.
I traced what happened during the first call to the ISR and only the TRANSMISSION_END flag is set in the routine, none of the rest.
Bob, the rccResetUSART call doesn't to make any difference unfortunately.
I have also observed what It could be happening in my setup is that there is probably some activity in the bus caused by other devices, and the result off that perhaps could be picked up by SD2 before the sdStart call and that could be causing the Tx complete interrupt somehow, this is pure speculation as I don't understand why that would trigger specifically the transmission complete when 1st it has not been enabled/registered and 2nd nothing got transmitted yet.
I believe this behavior is directly coupled to my system as if I disconnected my controller from the bus when the sdStart happens I don't see the initial unexpected interrupt that causes all the trouble. If not, and I don't wait enough before calling the event registration, the "spurious" initial interrupts is always present.
Thanks,
Raul
P.S. Giovanni, I assumed that your comment on filing a bug report is only relevant to Bob's last reply, not to the general discussion. Otherwise, let me know.