Helpful ReplyHot!Harmony PIC32MZ UARTS and RS485, issue with extra bytes.

Author
NicholasLee
Starting Member
  • Total Posts : 20
  • Reward points : 0
  • Joined: 2014/11/11 09:40:37
  • Location: 0
  • Status: offline
2017/09/18 16:06:50 (permalink)
5 (1)

Harmony PIC32MZ UARTS and RS485, issue with extra bytes.

I am implementing a Modbus RTU Slave device in a PIC32MZ using Harmony.
This communicates with a PC using RS485.
The usart uses the Dynamic driver model with the following relevant settings:
#define DRV_USART_PERIPHERAL_ID_IDX0              USART_ID_1
#define DRV_USART_OPER_MODE_IDX0                   DRV_USART_OPERATION_MODE_NORMAL
#define DRV_USART_INTERRUPT_MODE                   true
#define DRV_USART_BYTE_MODEL_SUPPORT            true
#define DRV_USART_BAUD_RATE_IDX0                    9600
#define DRV_USART_LINE_CNTRL_IDX0                   DRV_USART_LINE_CONTROL_8EVEN1
#define DRV_USART_HANDSHAKE_MODE_IDX0        DRV_USART_HANDSHAKE_SIMPLEX
 
The RTS line from the PIC is used to control the RX/TX direction of the external RS485 driver chip (via a logic inverter).
 
I can successfully receive packets from the PC into the PIC.
However, when packets are sent from the PIC to the PC, on inspecting the received packet, they are found to have been both suffixed and prefixed by a single unwanted 0x00 byte of data (which my code does not 'seem' to be sending as far as I can tell)
 
For example, the 5-byte sequence 01 84 02 C2 C1 sent by my PIC software would be received at the PC as  the 7-byte sequence 00 01 84 02 C2 C1 00 
 
This would 'seem' to be an artefact of the PIC or the Harmony drivers.
As I am using DRV_USART_HANDSHAKE_SIMPLEX, the CTS line 'should' be irrelevant to any of this.
The RTS line however is controlled by the Harmony Drivers rather than by my code.
 
Is there any way to control the timing between the RTS line being set to transmit, when the character is actually transmitted, and when the RTS line is dis-asserted again? I have no idea if the absence of such a "pre-delay" is a contributing problem, but I am reduced to guessing at this point.
 
#1
Jim Nickerson
User 452 _
  • Total Posts : 4267
  • Reward points : 0
  • Joined: 2003/11/07 12:35:10
  • Location: San Diego, CA
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/18 16:29:35 (permalink) ☄ Helpfulby NicholasLee 2017/09/18 17:12:20
4.33 (3)
maybe the 485 line needs a pull up/down to leave it in the right idle state before transmitting
#2
Jim Nickerson
User 452 _
  • Total Posts : 4267
  • Reward points : 0
  • Joined: 2003/11/07 12:35:10
  • Location: San Diego, CA
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/18 16:34:34 (permalink) ☄ Helpfulby NicholasLee 2017/09/18 16:50:57
4.67 (3)
From an old 485 guide "MODBUS over serial line specification and implementation guide V1.0"
http://www.modbus.org/doc...ver_serial_line_V1.pdf


3.4.6 Line Polarization
When there is no data activity on an RS-485 balanced pair, the lines are not driven and, thus susceptible to external noise or
interference. To insure that its receiver stays in a constant state, when no data signal is present, some devices need to bias
the
network.
Each MODBUS device must
be documented to say :
-
if the device needs a line polarization,
-
if the device implements, or can implement, such a line polarization.
If one or several devices need polarization,
one
pair of resistors must
be connected on the RS-485 balanced pair :
-
a Pull-Up Resistor to a 5V Voltage on D1 circuit,
-
a Pull-Down Resistor to the common circuit on D0 circuit.
The value of those resistors must
be between 450 Ohms and 650 Ohms. 650 Ohms resistors value may allow a higher number of
devices on the serial line bus.
In this case, a polarization of the pair must
be implemented
at one location for the whole Serial Bus
. Generally this point is to
choose on the master device or on its Tap. Other devices must not
implement any polarization.
The maximum number of devices authorized on such a MODBUS Serial Line is reduced by 4 from a MODBUS without polarization.
 


 

edit: to add link
post edited by Jim Nickerson - 2017/09/18 16:36:59
#3
NicholasLee
Starting Member
  • Total Posts : 20
  • Reward points : 0
  • Joined: 2014/11/11 09:40:37
  • Location: 0
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/18 17:10:16 (permalink)
0
Thanks, yes, I think we are onto something here.
I am using an FTDI USB-RS485-WE-1800-BT cable as my RS485 adapter.
I just found this webpage which mentions that getting extra zeroes can be a problem with this cable, and this issue is related to the fail-safe biasing you mentioned at the slave device's transceiver chip.
goo.gl/RC9Et1
I was using the SN75176BDR transceiver chip on my board, and this also does not incorporate any fail-safe biasing.
I've ordered a different part (MAX13485EESA+) which does contain internal fail-safe biasing.
(This should be a cleaner and more generalised solution than adding resistors to the outputs of the existing SN75176BDR)
I'll let you know in a few days if this fixes all (or some) of the problems I have been seeing.
#4
Jim Nickerson
User 452 _
  • Total Posts : 4267
  • Reward points : 0
  • Joined: 2003/11/07 12:35:10
  • Location: San Diego, CA
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/18 17:15:11 (permalink)
4 (3)
I have been adding resistors as needed for some time now.
I use an 83483 transceiver.
#5
muellernick
Super Member
  • Total Posts : 346
  • Reward points : 0
  • Joined: 2015/01/06 23:58:23
  • Location: Germany
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/19 08:10:35 (permalink)
3.5 (2)
My RS485 experiences ...
 
I'm using a LTM2881. NOT cheap, but isolated and no extra parts except a few resistors. No DC/DC converter required, all built in.
Not for Modbus, but a different industrial bus. Many winters ago, I wrote a Modbus slave, but forgot about all the timing.
 
Biasing:
I'm biased (pun intended) to say that only the master has always to implement biasing. No slave should have biasing (how many slaves will you add and how many of them do have biasing?).
 
Line termination:
Should be done, but can be left out (yes, not the way to go) at lower speeds and short connections.
 
Are you using two or four wire?
If two wire, there are timings to consider (and thus, you can go without biasing). If someone sends on the bus, he should set up the bus (bias it) and wait for three chars (depends on the protocol) and only then start sending. After the last bit has left the USART, he should still bias the bus and after a few chars release it. This timing can be tricky (milli seconds timing) and you have to thoroughly read the bus's specs in regard to timing.
 
Scope your bus!
 
HTH,
Nick
#6
Jim Nickerson
User 452 _
  • Total Posts : 4267
  • Reward points : 0
  • Joined: 2003/11/07 12:35:10
  • Location: San Diego, CA
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/19 08:20:39 (permalink)
0
I got bit by this errata, I was using TRMT to switch the 485 Transceiver.
I now use the TRMT Tx int to start a half bit timer to switch off the transceiver Tx.
 

Attached Image(s)

#7
bblessing
Super Member
  • Total Posts : 464
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/19 13:35:56 (permalink)
4 (2)
Jim,
 
    I read your first post with amusement, as I blew an entire day of development blaming my software when it turns out that my USB/485 converter had bit the dust. One of the eerie results was that I would get a 0x00 before and after any message that I sent on it. I replaced the SIPEX chip in the converter and everything worked again.
    Relevance to this post? Based on the evidence, you are very likely correct in your assessment. As for the errata, that really sucks as, like you, I use the TRMT bit to switch out of transmission for modbus.
#8
Jim Nickerson
User 452 _
  • Total Posts : 4267
  • Reward points : 0
  • Joined: 2003/11/07 12:35:10
  • Location: San Diego, CA
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/20 05:48:59 (permalink)
3 (1)
Many years ago ( pre 2003 ) I created a circuit like this app note  http://www.ti.com/lit/ug/tidubw6/tidubw6.pdf to resolve this problem.
I spent quite a bit of time trapping this on my scope before I read/saw/was aware of the errata when I switched to the pic32mx795
#9
qhb
Superb Member
  • Total Posts : 6255
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/20 17:46:59 (permalink)
3 (1)
I believe that is how TRMT works in most PIC USARTs
i.e. Asserted in the middle of the STOP bit, bad news if you're trying to flip bus direction.
 
One of these decades they may get TRMT right. i.e. asserted at the end of the STOP bit, and able to generate an interrupt.
 
 
 
#10
Jim Nickerson
User 452 _
  • Total Posts : 4267
  • Reward points : 0
  • Joined: 2003/11/07 12:35:10
  • Location: San Diego, CA
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/21 06:04:34 (permalink)
0
In my experience if it is active early it is mentioned in the errata.
#11
NicholasLee
Starting Member
  • Total Posts : 20
  • Reward points : 0
  • Joined: 2014/11/11 09:40:37
  • Location: 0
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/24 07:54:31 (permalink) ☄ Helpfulby stephaneC 2017/10/23 02:08:05
0
Hello,
To give closure on this, I have now fixed it, and my Modbus implementation now works perfectly.
 
As I am using an FTDI USB-RS485-WE-1800-BT cable as my RS485 adapter, (which has a moulded usb plug), there is no way to add biasing resistors at the 'master' end of the cable. These can only be added at the 'slave' device end, which is less than optimal.
 
I was using the SN75176BDR transceiver chip on my board, and this does not incorporate any fail-safe biasing.
I ordered a different part (MAX13485EESA+) which does contain internal fail-safe biasing.
Changing the SN75176BDR for the MAX13485EESA+ made no difference at all, which was disappointing given the amount of hype in the MAX13485EESA+ datasheet about how fail-safe it is.

I then added some 750ohm resistors (because that's the closest value I had in stock to 680ohms) as pull-up to 5V and pull-down to 0V on A and B respectively.
This fixed everything.
The software never had any bugs in it.
 
<RANT>
Luckily for me the TRMT bug present in the PIC32MX isn't present in the PIC32MZ chips I am using. The PIC32s are riddled with serious silicon errata and I have been bitten by several of them. I'm genuinely surprised they sell any given the number of major problems to work-around. 
One problem I have encountered is that if the A1 revision of the chip has an errata but the A3 revision doesn't, then Microchip has no way to selectively sell you the A3 chips without the silicon bugs.
There is a batch code printed on the chips, but the Distributors have no way to relate those codes to a silicon revision number.
i.e. They have NO silicon traceability in their supply chain. [let that fact sink in for a moment]
So, what silicon you get when you buy some chips is total pot-luck. I have tried talking to both Microchip and their Distributors and they just suggested we test each batch we get, to see what bugs they contain. This is a crazy thing to have to do in a production environment.
For example, the PIC32MZ A1 revision's primary oscillator won't work above 24 MHz, but the A3 revision works like the datasheet says it should.
Our product uses a 32MHz external oscillator, so depending which revision of PIC32MZ chip that we randomly receive through distribution, the finished products will either work or they will be scrap. That gets very expensive very quickly.
</RANT>
#12
muellernick
Super Member
  • Total Posts : 346
  • Reward points : 0
  • Joined: 2015/01/06 23:58:23
  • Location: Germany
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/25 00:13:42 (permalink)
3 (1)
Changing the SN75176BDR for the MAX13485EESA+ made no difference at all, which was disappointing given the amount of hype in the MAX13485EESA+ datasheet about how fail-safe it is.

 
That's why I never use MAXIM. Only exception is the MAX(3)232, but then, there are other sources.
 
Nick
#13
Jerry Messina
Super Member
  • Total Posts : 241
  • Reward points : 0
  • Joined: 2003/11/07 12:35:12
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/09/25 01:55:13 (permalink)
3 (1)
 MAX13485E/MAX13486E guarantee a logic-high receiver output when the receiver inputs are shorted or open, or when they are connected to a terminated transmission line with all drivers disabled

I'm curious... did you have the bus terminated?
 
Many of these "failsafe" receivers only work for shorts and opens. Once you add any sort of termination it defeats the internal failsafe mechaniism and you have to do it externally. This one sounds a little different.
 
I always do it externally anyway. That way I'm not tied to any special transceiver.
 
#14
jcandle
Super Member
  • Total Posts : 207
  • Reward points : 0
  • Joined: 2011/09/19 22:01:53
  • Location: 0
  • Status: offline
Re: Harmony PIC32MZ UARTS and RS485, issue with extra bytes. 2017/10/06 23:13:37 (permalink)
0
For a good industrial and isolated USB to RS485, get a SerialGear or B&B USBG-COMi-SI-M.  Screw terminals for the wires; jumpers inside for termination and failsafe.
 
I got bit by TRMT in dsPIC33F... it was fine if no parity and one stop bit...
#15
Jump to:
© 2017 APG vNext Commercial Version 4.5