Events for serial driver transmission completion

Discussions and support about ChibiOS/RT, the free embedded RTOS.
User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Events for serial driver transmission completion

Postby Giovanni » Mon Aug 14, 2017 9:53 pm

You should be able to verify this by placing a breakpoint in the ISR, if you hit it before start transmitting then your hypothesis is right and that would be probably a bug somewhere.

I am in my vacation place with no HW for a test.

Giovanni

User avatar
FXCoder
Posts: 384
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 180 times
Been thanked: 130 times

Re: Events for serial driver transmission completion

Postby FXCoder » Tue Aug 15, 2017 6:57 am

Just a thought for what it's worth...
Initialization of UARTs in hal_uart_lld.c does not explicitly reset the peripheral through APB rcc_reset.
If, upon enabling the GPIO to the UART, there was some activity on the GPIO, then the UART may respond.

To ensure reset state you could put an explicit reset of the USART via RCC and see if the errant event goes away.
I believe you only need set the reset bit and then when the USART is enabled (in start) the rccenable will clear the reset bit.
In any case that sequence works in some other code I have but I wasn't able to find a precise answer in ST community after a quick search.

Code: Select all

#if STM32_UART_USE_USART2
  rccResetUART2();
  uartObjectInit(&UARTD2);
  UARTD2.usart   = USART2;
  UARTD2.dmamode = STM32_DMA_CR_DMEIE | STM32_DMA_CR_TEIE;
  UARTD2.dmarx   = STM32_DMA_STREAM(STM32_UART_USART2_RX_DMA_STREAM);
  UARTD2.dmatx   = STM32_DMA_STREAM(STM32_UART_USART2_TX_DMA_STREAM);
#endif

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Events for serial driver transmission completion

Postby Giovanni » Tue Aug 15, 2017 12:02 pm

Does the reset procedure work before enabling the USART clock? in that point the clock is not yet enabled. Just asking, I am not sure myself, it could be a good idea to do this in all drivers.

Giovanni

User avatar
FXCoder
Posts: 384
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 180 times
Been thanked: 130 times

Re: Events for serial driver transmission completion

Postby FXCoder » Tue Aug 15, 2017 2:45 pm

Does the reset procedure work before enabling the USART clock?


That's a good question.
From looking at the ST block diagram of the USART it's not possible to see the effect rccReset/rccEnable have.
The APB clock is there but if UE, TE and RE are clear in CR1 then in theory the USART should be "dead".
However the reset bit should force the USART h/w to reset since APB clock is there and running.

I'm not setup to do testing right now.
And further web searching didn't turn up useful information.

If Raul can make a quick mod to the USART driver and then make some tests that would be enlightening.

FYI I noticed in the rccReset macro that the bit is set then cleared so my comment on rccEnable clearing reset was irrelevant.
Maybe it does that, maybe it doesn't.
An experiment for another day.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Events for serial driver transmission completion

Postby Giovanni » Tue Aug 15, 2017 2:50 pm

The reset could be addred in sd_lld_start() if the clock is required. Just taking care to place it few clock cycles after enabling the clock, this is a common cause of problems, the activation is not immediate.

Giovanni

User avatar
FXCoder
Posts: 384
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 180 times
Been thanked: 130 times

Re: Events for serial driver transmission completion

Postby FXCoder » Wed Aug 16, 2017 3:21 am

Hi Raul,
You could try adding rccResetUSART2() to your code just before calling sdStart().
This is a quick experiment confined to just the application level code only.
It assumes rccReset works regardless of the state of rccEnable.
Unknown at this time but worth a try.

Giovanni's suggestion to add rccReset after rccEnable in the lld drivers would be a more definitive test.

It does seem strange that the USART would do anything prior to being rcc enabled.
If I get some time later today I'll try some tests independent of Chibios drivers.
Maybe a test would be to set alt inputs, toggle RX, while USART is not enabled and see if anything gets set in the USART registers?

Bob

User avatar
FXCoder
Posts: 384
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 180 times
Been thanked: 130 times

Re: Events for serial driver transmission completion

Postby FXCoder » Wed Aug 16, 2017 5:05 am

Hi Giovanni,
This is probably an unlikely use case I'm considering but I guess it falls into the "good practice" category...

All the Chibios rccReset macros clear the entire register after applying the reset bits specified by the mask.
In the event that some other independent (non Chibios) driver code has intentionally set a Reset bit in the rcc register and that other driver code expects the bit to remain set until it clears it, then the current Chibios macro implementation would clear the bit.

So maybe change all rccReset macros to use RCC->xxxxRSTR &= ~(mask); ?

Bob

Code: Select all

/**
 * @brief   Resets one or more peripheral on the APB1 bus.
 *
 * @param[in] mask      APB1 peripherals mask
 *
 * @api
 */
#define rccResetAPB1(mask) {                                                \
  RCC->APB1RSTR |= (mask);                                                  \
  RCC->APB1RSTR = 0;                                                        \
}

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Events for serial driver transmission completion

Postby Giovanni » Wed Aug 16, 2017 12:39 pm

Could you post this in "bug reports"? there is the risk that it is lost in the noise. That forum is more actively guarded and posts closed once the fix has been applied.

Giovanni

Raul
Posts: 43
Joined: Thu Aug 13, 2015 5:15 pm
Has thanked: 3 times
Been thanked: 1 time

Re: Events for serial driver transmission completion

Postby Raul » Fri Aug 25, 2017 1:58 pm

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.
Last edited by Raul on Fri Aug 25, 2017 3:29 pm, edited 1 time in total.

Raul
Posts: 43
Joined: Thu Aug 13, 2015 5:15 pm
Has thanked: 3 times
Been thanked: 1 time

Re: Events for serial driver transmission completion

Postby Raul » Fri Aug 25, 2017 2:14 pm

Edit: Duplicate post
Last edited by Raul on Fri Aug 25, 2017 3:31 pm, edited 1 time in total.


Return to “ChibiOS/RT”

Who is online

Users browsing this forum: No registered users and 16 guests