K64 UART Communicating with Multiple KL26s and KL27s

[philhale]

I have a central controller utilizing a K64 MCU that communicates on a UART buss to multiple devices which use KL26s and KL27s MCUs in a master-slave mode. Everything works pretty well up to about 8 or 9 devices. At that point, communications begin to break down.

I put a scope on the lines but everything appears okay. I have my EE checking my scope on Monday morning to verify. My thought is that the boards have some type of pull up on these lines and eventually it becomes to hard to pull the lines down and communication fails.

Because my system is modular in design, I can prove without a doubt that the number of devices is the culprit.

Has anyone experienced anything like this?  Can you recommend a solution?

[mjbcswitzerland · Accepted solution]

Hi Phil

If pull-ups are enable on the UART receiver lines this represents a load of between 20..50k for each slave - probably around the 20k end on average. 10 slaves would make about 2k, which is still not low impedance for the transmitter.

If you use low power mode you should find this define:

 #define UART_PULL_UPS  (PORT_PS_UP_ENABLE)                           // activate pull-ups on UART lines to avoid them floating in low power modes (which causes leakage currents to flow)

If you comment it out the UARTs will not use pull-ups.

Also check adding additional resistors to see whether there is a limit to the drive level.

To use higher drive strength at the Tx change

#define UART_PULL_UPS  (PORT_PS_UP_ENABLE | PORT_DSE_HIGH)

in case of drive problems I expect that this will be seen at the scope as bad logic levels or slow slew rate.

If you work in a polling environment are you sure that there is not a problem with the polling cycle time when the number of slaves is increased rather than an electrical issue?

Regards

Mark

[philhale]

Mark,

Thanks for the quick reply. I am not using the UART_PULL_UPS define at this time. I am not using lower power mode either. I will try as you are suggesting.

I am polling all boards and waiting for a response from each board individually. Each poll has a specific defined timeout window so the number of units should not be an issue. Additionally, regardless of the number of active boards the same number of calls are made to all the "possible" boards so the number of packets each board will see is finite and predictable. I should not be overrunning any buffers using this method or it will be happening with each.

I have put a logic analyzer on the UART lines and I see the messages being sent from the K64 in perfect timing but I don't see a response from excess boards. When I put those boards in debug mode, I see the first few packets coming in (after reset only) but then the UART handler just stops receiving any more characters. When I remove a fellow board, the problematic board magically starts working again without any touch or reset. It just starts working again. This is why I think the issue is a drive problem.

Thanks again.

Phil

[philhale]

Mark,

You were correct on a couple of suggestions.

First, you were correct that the pull up was necessary on the drive line. I put the pull up and extra drive on the master MCU (K64) and now all (slave) boards see the commands sent from the master.

Second, once the boards saw all the traffic coming through this caused a problem overrunning my slave board buffers. This meant that your theory regarding the polling being a problem was also true. I'm working on that problem now.

Finally, there was also a bad KL27 chip on one of the boards that shorted the UART lines. This was a later introduced problem that occured when I was testing the various configurations of slaves.

Thank you for your suggestions. They sent me looking in the right direction!

Phil