Is there a problem with the RS-485 output enable signal on the LPC824?

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

Is there a problem with the RS-485 output enable signal on the LPC824?

Jump to solution
3,808 Views
djrose
Contributor III

I have been looking at using an LPC824 instead of an LPC812 to connect to an RS-485 communication line.

Specifically, I am now testing the functionality provided by the RS-485 output enable signal.  Section 13.5 or the user manual states:

When RTS signal is configured as an RS-485 output enable, it is asserted at the
beginning of an transmitted character, and de-asserted either at the end of the character,
or after a one character delay (selected by software).

What I am seeing is basically as described, but with a very small pulse in the signal between the end of one character and the start of the next.

Here is a logic analyzer trace showing what I describe:

Auto485Control.PNG

The top trace shows the six characters being transmitted.

The third trace shows the RS-485 output enable signal - With the pulses in question.

The second trace shows a signal I create with a GPIO - functionality exported from an LPC812 project.

I can possibly put something in the line to filter this glitch out, but I don't see that it should be necessary,

Labels (1)
1 Solution
2,924 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi David Rose,

    Thanks again for your patience.

    After the detail checking from our designer team, I already get the reply, yes, you are right, the LPC845 485 really have this problem. Actually, 824 MP first, 80x, 84x MP later, designer found this problem in 824 and fixed it on 80x/84x.  That's why the LPC80X/LPC84X don't have this problem.

   So, if you very care about it, we highly suggest you choose LPC80X/LPC84X for the 485 function.

Wish it helps you!


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

17 Replies
2,924 Views
djrose
Contributor III

Hi Kerry,

I've created a minimal version of one of my projects for the LPCXpresso824-MAX boards

You can grab a copy of the project source from:  HERE 

Please read the file in the archive !Notes!.Txt for specific details

If required, I could quite easily create similar projects for the LPC845 and LPC802.

Regards,

David

0 Kudos
2,924 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi David Rose,

   Thank you for your updated information and code sharing.

   But, I don't know why, I can't open your project source link.

   Could you upload it directly to the community? Or you can just post the source code about the 485 control, I will add it to our official project.


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,924 Views
djrose
Contributor III

Hi Kerry,

I'm attaching the project files here.

I've now also done a similar project for the LPC802 Xpresso board.  It has the same basic layout, so please refer to the corresponding source files (given in the readme of the LPC824 project) to see the setup detail.

0 Kudos
2,923 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi David,

   Thanks a lot for your project.

   I have tested your code on my LPCXpress lpc824 board, this is my test wave, a little different with you:

pastedImage_1.png

But I think it is not the problem, as you have post, the user manual already say:

pastedImage_1.png

So, I think the RTS wave is correct. The glitch just means one byte is transmit, then the RTS is de-asserted. I think this glitch won't influence your usage, do you meet some problems with this glitch?

About LPC802, I still don't have that board, I will find a board and test it again.

From the LPC802 user manual description, it should also have that glitch.

Any updated information from my side, I will let you know!


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,924 Views
djrose
Contributor III

Hi Kerry,

Your waveform is basically the same as my original (just inverted).

I still think you are wrong with your interpretation of what is said about the RTS signal.  Having a glitch, however small just doesn't make sense.  And looking at the trace, I suspect that the hardware is producing the glitch on the start bit of a byte - Since there is no glitch between the last stop bit of the transmission:and the delayed de-assertion of RTS.

If you are right with what you say about the glitch being there then I agree with what you said:

From the LPC802 user manual description, it should also have that glitch.

But I don't.  I see no glitch on the LPC802 or LPC845.  So clearly something is wrong (even if it's my code).

You really do need to compare the trace of the LPC824 with that of the LPC802 or LPC845.

You say you don't have the LPC802 at the moment. Do you have access to an LPC845 board - I can provide an equivalent project for that.

This is not an issue for me at the moment, but seeing what I have, I would now instinctively avoid the LPC824 for RS485 use.

0 Kudos
2,924 Views
djrose
Contributor III

Hi Kerry,

Looks like this has gone quiet.  I guess you've not managed to acquire an LPC802 or LPC845 for testing.  They're easily available in the UK.

Probably sensible for me to provide a little more evidence for you.  Here are waveforms using the same setup from an LPC802:

!Capture.PNG

With the OETA bit clear.

!Capture-OETA.PNG

With the OETA bit set

As can clearly be seen, there is no pulse in the Output Enable signal between bytes.

Both my capture and yours from the LPC824 showed pulses in the Output Enable (RTS) signal between bytes.  You mentioned that the pulses were to be expected and you would expect to see them on the LPC845 and LPC802.  Since no pulses are present on the LPC802, there is clearly some mismatch and therefore something is incorrect.

The action I see on the LPC802 makes much more sense and matches what I've seen on other devices in the past, so I still believe it is the action of the LPC824 that is incorrect.

Your comments on this would be appreciated.

Thanks.

2,924 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi David,

    Sorry for my later reply.

   I have got the LPC845 board, please also send me your LPC845 485 testing code, I will test it between the LPC845 and LPC824  on my side.

   If it is really the LPC824 problem, I will report it to our according department.

   You can send all your LPC845, LPC824, LPC802 project to me together now.


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,924 Views
djrose
Contributor III

Hi Kerry,

Here is an updated archive.  Same code for LPC824 and LPC802.  Added code for LPC845.

Kind regards,

David

2,925 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi David Rose,

    Thanks again for your patience.

    After the detail checking from our designer team, I already get the reply, yes, you are right, the LPC845 485 really have this problem. Actually, 824 MP first, 80x, 84x MP later, designer found this problem in 824 and fixed it on 80x/84x.  That's why the LPC80X/LPC84X don't have this problem.

   So, if you very care about it, we highly suggest you choose LPC80X/LPC84X for the 485 function.

Wish it helps you!


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

2,924 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi David Rose,

    Thank you for you code, and thank you for your patience.

    I have got all the LPC802, LPC824, LPC845 board on my side, today, I test it with your code in all the lpc802, LPC824, LPC845 board, the same uart configuration:

  LPC_USART0->CFG = (UART_CFG_ENABLE)                           // Enable UART operation - Specify parameters
                  | (UART_CFG_DATALEN_8)
                  | (UART_CFG_PARITY_NONE)
                  | (UART_CFG_STOPLEN_1)
                  | (UART_CFG_OESEL  |UART_CFG_OEPOL  |UART_CFG_OETA);

and check the user manual again.

I highly agree with your point, the LPC824 RTS wave is really abnormal.

Because, when OESEL=1, OETA=1, should like this in the user manual:the Output Enable signal remains asserted for 1 character time after then end the last stop bit of a transmission.

But from this WAVE:

pastedImage_4.png

After stop bit, the RTS should still wait for 1 character, but in LPC845, the RTS is desserted.

Anyway, I will report this problem to our according department, and thanks a lot for your good question.

Here, I post the LPC802, lpc824, lpc845 test wave, just for the post completeness.

1. LPC802

pastedImage_5.jpg2,LPC824

pastedImage_6.jpg

3. LPC845

pastedImage_7.jpg

If I get any updated information, I will let you know.

Have a great day,
Kerry

 

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,924 Views
djrose
Contributor III

Hello Kerry Zhou,

Sorry, but I have a different interpretation of the detail in the manual.

I have OETA asserted. So, as you have highlighted:

If selected by OESEL, the Output Enable signal remains asserted for 1 character time after then end the last stop bit of a transmission.

There is no mention of any de-assert there. And in that same block it also states:

OE will also remain asserted if another transmit begins before it is de-asserted.

Again, no mention of a de-assert (brief or otherwise).

But also, as the trace I gave shows, at the end of the last byte transmitted, the Output Enable signal does not pulse before remaining active for one character time.

This suggests to me that the Output Enable line is in fact pulsing once a character has been placed in the Transmit Data Register. Why would it do that?

I am loading the Transmit Data Register under interrupt control, so the transmission should be almost continuous; i.e., no intentional gap between the stop bit of one character and the start of the next.  I believe that the Output Enable signal should remain continuously active during this transmission. 

I have code that controls the RS-485 driver via a GPIO pin with reasonably good accuracy - Code that I originally created for the LPC812.  This code (unsurprisingly) works on the LPC824, but it really would be nice to make use of the extra facilities provided by the LPC824 and it would free a timer (that I use in my implementation).  The lowest trace I gave on the analyzer screenshot shows this working.

I'm fairly sure I will be able to do something to filter out this pulse to ensure that it does not cause me any issues, but it's not really sensible for me to require it.

0 Kudos
2,924 Views
djrose
Contributor III

As a follow up to this thread I think it is worth adding the following detail:

Since trying this test on the LPC824, I've now acquired an LPC845 and LPC802.  It was not difficult to port the functionality of the test carried out with the LPC824 and repeat it with these two newer devices.

Both operate as I expected and not as shown previously on the LPC824; i.e., there were no glitches in the RTS (RS485 Transmit Enable) signal between characters.

So, if anyone wants the CPU to accurately control the Transmit Enable signal on RS485 I would suggest that they consider the LPC845 or LPC802 in preference to the LPC824.

Maybe NXP should consider adding detail to the Errata Sheet for the LPC824.

0 Kudos
2,924 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi David Rose,

   Thank you for your updated information, this is very useful!

    Could you share your code which will reflect the problem in LPC824? I will test it on my side with LPC824 and LPC845, if this problem is reproduced, I will report this problem to our according department, may add this in the updated errata sheet.


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,924 Views
vojtechhavlicek
Contributor III

I´ve tried to solve this problem too. I´ve finally used software control. Could you show the code for the initialization of the pins for RTS?

0 Kudos
2,924 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hello Vojtech havlicek,

   Now, what the method you want to use? Hardware RTS pin control or the GPIO  RTS pin control?

  Do you need the UART hardware RTS pin control code? Not GPIO.

  Actually, just like the user manual have described, it is OESEL,OEPOL, and OETA bits in the CFG register.

  Please confirm it at first.


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,924 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hello David Rose,

   Actually, from the LP824 user manual description, I think this phenomena is the normal result.

   As you know,

pastedImage_1.png

It is a transmission, so it should one byte transfer, that's why you have a de-assert after each byte.

Now,  whether this De-assert influence your normal 485 communication?

If your hardware still working OK, I think you don't need to mind it. Otherwise, just as the user manual said:

pastedImage_2.png

You can use the GPIO as the RTS direction pin.

Wish it helps you!

If you still have question about it, please let me know!


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,924 Views
djrose
Contributor III

Hello Kerry,

I would value any comments you might have on the last post I made in this thread

It would be nice to understand this situation more fully before I actually implement a solution.

Regards,

David.

0 Kudos