UARTx_SerialSetup

[microchip-mplab-harmony]

UARTx_SerialSetup

[vishalnxt]

@picerno76 , Can you tell which device you see this issue?

[picerno76]

it's a PIC32MX150F128B

[vishalnxt]

@picerno76 , thanks for pointing out the issue. I am raising an internal ticket to get this fixed.

[picerno76]

Thank you. However, as I read in the documentation, this issue isn't only for this device but for all PIC32s

[vishalnxt]

@picerno76 , you are right. Bunch of bits in the UxSTA register are cleared when UART is disabled. You need to set some of these bits again after re-enabling the UART.

[picerno76]

of course I have already done it. I found out another issue. Sometimes when I change SerialSetup, if I'm receiving bytes on my UART the error interrupt flag is setted and never exit from interrupt service routine because OERR, FERR and PERR aren't setted

[vishalnxt]

@picerno76 , does it help if the UART is not disabled (and re-enabled) in the serial setup API?

[picerno76]

If I remove the disable/enable code, it seems that I don't have any issue, but I don't know if could be another hidden one. If you put that code for a reason, could be enough to set UTXEN and URXEN and clear UxEIF before enable the UART

[vishalnxt]

@picerno76 , well, the idea of disabling UART before changing the baud rate was to make sure that the baud rate is not changed while an active transmission is underway. Of course, this will not work well if a data reception is already underway as is in your case. Maybe a better solution is to wait for the RIDLE (Receiver Idle bit) bit in the UxSTA register before disabling the UART. But again, I don't think this a full-proof solution as receiver can again become active before the UART is disabled. In that case, the UART can be left enabled so that it generates RX errors normally. However, application must ensure that no transmission is underway before calling the serial setup API.

[picerno76]

well, the idea of disabling UART before changing the baud rate was to make sure that the baud rate is not changed while an active transmission is underway.

I undestand

Of course, this will not work well if a data reception is already underway as is in your case. Maybe a better solution is to wait for the RIDLE (Receiver Idle bit) bit in the UxSTA register before disabling the UART. But again, I don't think this a full-proof solution as receiver can again become active before the UART is disabled.

I agree

In that case, the UART can be left enabled so that it generates RX errors normally.

if you think it isn't a problem, of course it can be left enabled. I don't remember from what version I have updated my local repository but in tha past I didn't have this issue. Was it always enabled in previous versions?

However, application must ensure that no transmission is underway before calling the serial setup API.

if the application uses the driver, it cannot know if there is an underway transmission or am I wrong? However I didn't want to change the setup during a transmission but it happens in my initial setup in a board connected on a RS485 bus where there is already traffic

[vishalnxt]

if you think it isn't a problem, of course it can be left enabled. I don't remember from what version I have updated my local repository but in tha past I didn't have this issue. Was it always enabled in previous versions?

This change is recently introduced in csp v3.13.0. Older csp version does not have this change for pic32mx devices.

if the application uses the driver, it cannot know if there is an underway transmission or am I wrong? However I didn't want to change the setup during a transmission but it happens in my initial setup in a board connected on a RS485 bus where there is already traffic

You can use the DRV_USART_BufferStatusGet API to know the status of a submitted transmit request. You can also keep track of status of a transmit request by registering a callback with the driver and making sure you received a callback for all the submitted requests.

[picerno76]

This change is recently introduced in csp v3.13.0. Older csp version does not have this change for pic32mx devices.

I tried to switch to csp 3.12.0 in the content manager but the generator made the same code. Ok, I possibly made a mistake

You can use the DRV_USART_BufferStatusGet API to know the status of a submitted transmit request. You can also keep track of status of a transmit request by registering a callback with the driver and making sure you received a callback for all the submitted requests.

sure but this isn't my case. In the initial state, I haven't submitted any request yet

[vishalnxt]

@picerno76 , just checking if you are still blocked on this issue?

[picerno76]

the 3.13.1 version has fixed the issue. thank you