Modbus RTU on TWR-K20D72M

[Felix]

Hi Mark,
somewhere on nxp.com you wrote, that the uTasker MODBUS module runs together with the NXP tower board TWR-K20D72M. This makes me hope, that you´ve already tried it with this hardware. It´s also supported in the code. How do you connect this board to RS485. I can´t get any connection to the board using TWR-SER or TWR-IND-IO serial modules. Maybe the reason for this could be, that the only UART with flow control between the boards is UART1 and this one is also used by the onboard OSBDM debugging circuit on the main board. Have you ever tried this combination with Modbus RTU?
If yes, maybe you can help me with my setup?!
Best regards Felix

[mark]

Felix

I have used Modbus on many parts and as long as you set up the correct UART (and possible its mux pins) there will be no problems with this HW configuration.

Make sure you select the appropriate UART channel with
#define MODBUS_UART_0    1
(would put the first Modbus serial connection on UART 1 in this example)

Don't use Modbus RTU over OpenSDA connections since they don't work, if I remember correctly - use a "real" UART/RS232/RS485 connection.

For RS485 check that the RTS signal is correctly connected if semi-duplex, otherwise RS485/RS232 has not operational difference.

When tower boards are connected there is often an automatic switch-over of the UART path between the OpenSDA and the SER board - check the circuit diagram for details.

I would also first put the debug interface onto the UART that you want to use so that you can easily verify that it is 'physically' working. Solve any potential HW settings to get it operating and then switch to Modbus instead, which will probably then also function.

Regards

Mark

[Felix]

Hey Mark,

Thank you for the fast response.
I can measure a valid RTU signal and RX is forwarded to the µC. But there is no reply on TX. If I put the DEMO UART on UART1 I can see messages on TX, so my hardware setup should be okay.
The Modbus channel is also selected as you mentioned and I don´t connect OpenSDA.
Is there any other software module which could block transmitting on UART1?

Thanks for your help and regards
Felix

[mark]

Felix

The first thing that I would do is run the project in the simulator, set a break point in the UART interrupt routine and inject a signal (eg. by using the UARTs menu). If the break point is hit you have the UART configured - then step the code to see that it calls the RTU HW timer, after which it will also hits its interrupt after the input frame has been received.

Once you are sure that this is correct (SW setup is as expected) repeat on the HW - any differences should pin point what is going wrong.
Also don't forget that the MODBUS slave will have an address so will only answer on the correct address. Check which address is being used if the UART is operating but the not returning a response.

Regards

Mark

[Felix]

Hi Mark,

thanks for your reply.
I´m pretty sure now, that it´s a software problem because I can run a self build application that is sending RS485 signals on the same hardware. The slave adress should also not be the reason because I use a master application on my PC which scans the hole adress range.
What I actually want to do is very easy: A single Modbus slave on UART1. 
I'm trying to get your initial example project to work as described in the Modbus user´s guide without any success.
The tranceiver (via UART1) on my TWR-IND-IO board gives some messages to the controller (RX) and there´s some toggling on RTS pin (200ms) but no response on TX.
What else should I take into account? Could some other code in the background affect the UART1 transmission or something like that? Do you maybe have example code for a similar configuration?
Hope you can give me a clue once again ;-)

Regards Felix

[mark]

Felix

I just checked on TWR-K20D72M with TWR-SER2 (I don't have a TWR-IND-IO).

1. The default Modbus UART is 1 - so doesn't need any change.
2. The default debug output is 1 so this would conflict - I set this to 0 just to free the Modbus UART.
3. I kept the TWR-SER in RS232 mode to check the connection (that is on the TWR-SER J17 set to pins 1-2 and J19 set to pins 1-2)
4. Using a Modbus master I could communicate via the DSUB connection on the TWR-SER  board - in ASCII mode at 19'200 Baud on slave address 33.

To use RTU one needs to change the settings in modbus_application.c
cMODBUS_default[]
from
(MODBUS_MODE_ASCII | MODBUS_SERIAL_SLAVE | /*MODBUS_SERIAL_GATEWAY | */MODBUS_RS485_POSITIVE),
to
(MODBUS_MODE_RTU | MODBUS_SERIAL_SLAVE | /*MODBUS_SERIAL_GATEWAY | */MODBUS_RS485_POSITIVE),

To change the Baud rate
SERIAL_BAUD_19200,                                               // baud rate of serial interface - serial port 1
can be changed to the one that is desired.

Beware that these settings are stored in Flash and new values are only valid after deleting flash (the parameter system) or by changing the value of MODBUS_PAR_BLOCK_VERSION in case they are saved in flash and taken as valid settings.


When using this interface the tower board should be supplied by USB connection connected to the active elevator board - if supplied by the debug connector the board will switch the UART connection to the VCOM port in the debugger and so the TWR-SER board UART won't work (rx will not be connected).

When using RS485 the RTS signal will need to be connected. The output on PTE3 is driven high (controlled by the setting MODBUS_RS485_POSITIVE) when transmission is in progress but the TWR-K20D72M doesn't connect this line. It also has a non-connected 0R resistor in the path. For some reason, if the 0R resistor is inserted, it connects to PTC3 which is a GPIO and has nothing to do with the UART. However the RS485 on the TWR-SER board is a full-duplex one and I don't think that this signal is needed.
In addition, the RTS is connected to the receiver enabled (normally I expect it to control the transmitter (?)).

In any case I don't find any problem with the operation as long as you use the correct Modbus settings (Baud rate, Slave address and RTU/ASCII mode).

Regards

Mark

[Felix]

Hi Mark,

thank you a lot for checking this for me on your board. This is really great support!
But sorry, I still havn´t got it. 
I prefer TWI-IND-IO because it has a half-duplex transceiver on it and I just have a two-wire converter. But I also tried the TWI-SER board. How do you connect the full-duplex board to the master? Do you have a 4-wire-RS485 to USB converter? I did´t find such a device. Do you think it could be okay to connect the positive and negative pins each togehter to get half-duplex transmission?

To my current issue: I think you´re right, that it has something to do with the RTS pin. I´ve now connected PT3 direct to the transceivers DE pin but there´s no signal (0 V) on it.
The above described toggling was on pin PTC7 which is defined as RTS1 on both serial tower boards. I´m a little confused about your explanation of the RTS pin connection.
On my board (TWR-K20D72M) there´s no 0R resistor on this path and PTE3 goes direct to the expansion header. I also did not find the descibed connection to PTC3 on the schematics.
By the way I soldered R35 on the mainboard to connect PTE0 as TX. UART1 (RTS,RX,TX) is now directly connected to the transceiver via expansion header.

In the original software I changed just the following things:

• swap comments of #define FRDM_K64F and #define TWR_K20D72M in config
• in config.h: uncommented USE_MODBUS
• in app_hw_kinetis.h DEMO_UART from 1 to 0
• in modbus_app.c: MODBUS_MODE_ASCII to MODBUS_MODE_RTU

                                                   
With an USB-to-RS485 converter I try to poll slave adresses 0 to 254 (19200 Baud) without any response and I can´t see any signal on RTS or TX.
Did I miss something or do I need a new mainboard? ;-)

Best regards
Felix

[mark]

Felix

I would check signals directly on the K20's pins (1, 2 and 4) to be sure that signals are really there. A lot can go wrong with the Tower boards since signals have to be traced across at least three boards with various jumpers in the chain.

If the RX signal arrives (with correct settings) you will see transmission shortly after, with pin 4 pulsing high (this is what I measured to be sure, although I was using RS232 for the actual Modbus communication connection). Since RS232 and RS485 differ only at the electrical level the test that I did will have verified the operation up to the chip's pins.

Beware that PTE3 is connected to the back-plane (elevator) directly but is not used by the TWR-SER board.

I'll take a look at the TWI-IND-IO diagram to see whether it needs different routing or not.

Regards

Mark

[mark]

Felix

I checked the TWR-IND-IO diagram and it doesn't look as though its isolated RS485 works together with the TWR-K20D72M.

For example, the receive signal is connected to C41 of the secondary elevator, meaning that the correct secondary elevator needs to be used (not a dummy one). However, the TWR-K20D72M doesn't support any connections on the secondary elevator.

Do you agree with my observations?

Regards

Mark

[Felix]

Hi Mark,

I double checked the connections. All three lines are connected between RS485 transceiver and uC via UART1.
On RX there´s some data transmission during polling. TX is permanently high and RTS is low.
I agree with you that the connection of the transceiver is similiar on both serial board, so in my opinion both of them should run with the right connection of RTS. Although I have no idea at the moment, I will give it another try later. Maybe I will look for another hardware.

Regards
Felix

[mark]

Felix

According to the TWR-IND-IO circuit diagram on the NXP web site (Rev B from 2012) UART1 is connected to a 4 pin header and RS485 is connected to UART 2. Do you have a different revision?

What would be the connection chain for the RS485?

According to my diagrams it would be (starting with TWR-IND-IO)
- RS485 J22 or J23
- J20 jumper 1-2
- Secondary elevation (J1B) J41
- no further connection

What does your board/circuit do?

Regards

Mark

[Felix]

Hi Mark,
I connected several UARTs, including UART2 via J20 and UART1 via J8 (it´s the same revision).

But there is another Jumper (J6) which connects 5V to the serial board so that the UART level at the controller is also 5V. This Jumper was set by default to 5V on my board (in contrary to the quick start guide). The k20 datasheet may say that 5.5 V is okay for IOs but who knows ...?!

Anyway I can´t communicate with any UART even the DEMO console doesn´t work anymore.
I ordered I new board and will give it a next try in a few days.

Thanks a lot for you help
Felix

[Felix]

Hi Mark,

as I already feared, this wasn´t my problem. I now have two mainboards on two different towers, one with TWR-SER and one with TWR-IND-IO with no modbus communication on neither if them.

Here my current setup for UART1:

TWR-SER:
J15, J17, J18, J19 - all set to 2-3
all other jumpers unconnected

TWR-K20D72M:
as new, but R35 populated

Primary Elevator:
B11 (PTE3/UART1_RTS) connected with B21 (ELE_RTS on TWR-SER)

TWR-IND-IO:
J8 connected to J20 (RX->RX; TX->TX; RTS->RTS)
all other jumpers unconnected

TWR-SER is connected via RS422 to USB
TWR-IND-IO via RS485(A/B) to USB
(I already tried different converter cables)

The firmware is the one from the repo with the above explained changes.

Do you see any difference to your setup which could have an influence here?
If not, could you maybe give me your test project to exclude any software issues.

Thank you again and best regards.
Felix

[Felix]

Hey Mark,

I was right with my guess with the broken board. Now I have at least communication on the UART1 on the new board. RX and TX seem to be valid and RS232 should run now (can´t test it at moment).
But on RTS I´ve exactly the same signal like on TX, also with the same polarity. Changing MODBUS_RS485_POSITIVE to MODBUS_RS485_NEAGATIVE has now influence on this.
Do you know this hehaviour?

Regards
Felix

[mark]

Hi Felix

When I tested I was seeing a positive pulse on RTS when Tx data was transmitted.
Note that the Tx singal is '1' in idle state and the data is seen as pulse low.
If you see the same signal on Tx and RTS it may be that you have the two lines sorted together - I tested directly on pin 4 of the processor.

Regards

Mark