UART-RS485 introduce unnecessary delays

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

UART-RS485 introduce unnecessary delays

Jump to solution
1,072 Views
vines
Contributor III

Hi,

I hope somebody can help me with my current issue. First, I will give a brief introduction to what I am using.

MCU: K60

RTOS: MQX 4.0

Compiler: cw10 ( I cannot convert to KDS or Expresso with gcc as I time won't allow me to port over)

Serial Used: UART4 with a medium priority interrupt

System:

Master and Multiple Slave (Polling method - half duplex)

adjustable Baud (19200 to 115200)

Problem:

Unnecessary delays in between Master query and Slave response

Scenario 1:

Baud 19200

Master continuously polling (round robin) to all slaves.

Result:

As you can see from the figure below, there was a delay of approximately 13ms between the master query and the slave's response. In my code, I did some processing in between but not too drastic that will cause 13ms. I tried to debug the code on the slave's side, I found out that the OnBlockReceived (Processor Expert generated) didn't fire until 9ms later after the last byte of the master query was received. Since I am on interrupt, I should be able to get the trigger from the moment I receive the first byte. However, the OnBlockReceived triggered me not only on the last byte but with an addition of 9ms delay. Hence, my code was able to process the received data only then. The figure below was captured when the master is continuously polling the slaves (I am not on debug or I didn't halt the system). The next figure and scenario below will give out further evidence on the delay.  

pastedImage_3.png

Scenario 2:

Baud 19200

Master is on debug allowing 1 step through to the target slave. 

Same setup and code as Scenario 1. But instead of running the code I put a halt allowing 1 poll at a time.

Result:

As you can see from the figure below, the delay between the master query and the slave's response was shortened considerably to 4ms. This is acceptable to me. So this somehow coincides with my reading of additional 9ms delay by the late trigger of the interrupt. If you add the 2 it will end up 13ms delay.  

pastedImage_4.png

I did a similar test using a 115200 baud rate. It becomes worst. 

Scenario 3: 

Baud 115200

Same setup and code as Scenario 1. 

Result:

As you can see the delay was even worse than 19200. The delay now is roughly 35ms. But again, when I did a step through on the code the delay is minimized. See Scenario 4. 

pastedImage_5.png

Scenario 4: 

Baud 115200

Same setup and code as Scenario 2. 

Result:

As you can see, the delay was also around 4ms same as at 19200 baud when doing a halt on the debugging.  

pastedImage_6.png

Additional info:

The data is complete and correct. I don't have any issue with the integrity of the data. It is only the additional delay that I am having issues. 

Code snippet:

I have a circular buffer in my code where I store the data I obtained from the UART. I retrieve the data 1 byte at a time. Again, as mentioned data integrity is not an issue. I can receive and send the correct data without a problem. 

void Hal_Mcu_Rs485_OnBlockReceived(LDD_TUserData *UserDataPtr)
{
   m_Rs485BufCtrHead++;
   if (m_Rs485BufCtrHead > RS485_BUF_SZ)
   {
      m_Rs485BufCtrHead = 0;
   }
   PROCEXP_RS485_ReceiveBlock(m_pRs485,(void*)&m_Rs485Buffer[m_Rs485BufCtrHead],1);
}

I know that this is probably longer to your liking but hopefully somebody can help me or at least point me to a correct direction on how to fix this problem. I will appreciate any help that is given.

Thank you very much and have a good day!

0 Kudos
1 Solution
841 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi Vines:

I would suggest you test this delay with a bare metal spi driver, if the delay is acceptable, you can port this driver into MQX RTOS.

Regards

Daniel

View solution in original post

0 Kudos
5 Replies
841 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi Vines:

Could you let me know how many tasks in your system and their priority?

Could you try to change this macro BSP_ALARM_FREQUENCY from 200 to 500, and then rebuild all bsp and psp, to see whether it help?

Regards

Daniel

0 Kudos
841 Views
vines
Contributor III

Hi Daniel,

Thanks for the reply.

Actually, I am running with only 1 task for the sake of testing.  I did suspect that it might have contributed to the delay. Unfortunately, it is still the same.

In addition, I set the macro BSP_ALARM_FREQUENCY to 1000.

Thanks.

 

 

0 Kudos
842 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi Vines:

I would suggest you test this delay with a bare metal spi driver, if the delay is acceptable, you can port this driver into MQX RTOS.

Regards

Daniel

0 Kudos
841 Views
vines
Contributor III

Hi Daniel,

Sorry for the late reply. I found the problem. It is actually on my code. Nothing to do with the MQX. Thanks anyway.

0 Kudos
841 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi Vines:

Thanks for your update.

Have a nice day!

Regards

Daniel

0 Kudos