BufferedSerial pin assignments not following documentation - FRDM-K64F bug

Mbed OS Bugs
1

Hi,

I’ve created a class that uses a BufferedSerial object for communication with a serial LCD. The board is unidirectional in that it only needs Tx connected. The documentation for BufferedSerial says the following:

TX and RX pins - you can specify either pin as Not Connected (NC) for simplex (unidirectional) communication or both as valid pins for full duplex (bidirectional) communication.

I’m able to do this on a FRDM-KL46Z board where I set the Tx pin to one of the UART Tx pins and “NC” for the Rx in the constructor of the BufferedSerial object. When I try to use the same code on a FRDM-K64F board, albeit with a different Tx pin, the NC assignment throws a runtime error:

++ MbedOS Error Info ++
Error Status: 0x80FF0144 Code: 324 Module: 255
Error Message: Assertion failed: pin != (PinName)NC
Location: 0x85F7
File: ./mbed-os/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/api/pinmap.c+27
Error Value: 0x0
Current Thread: main Id: 0x1FFF21DC Entry: 0x91CD StackSize: 0x1000 StackMem: 0x1FFF0C30 SP: 0x1FFF1AD0 
For more info, visit: https://mbed.com/s/error?error=0x80FF0144&tgt=K64F
-- MbedOS Error Info --

I can get it to work by assigning a valid Rx pin for that UART but this means the docs on BufferedSerial are incorrect.

Is this a bug for this boards pin maps or am I missing something?

2

Might have found the issue but need confirmation.

Under /mbed-os/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/serial_api.c there are two calls to pin_function() in serial_init_direct() without a check to see if each pin is an NC. If you dig into pin_function() you’ll find that it assumes the pin is not NC and will throw an assertion otherwise.

Starting at line 66 it currently looks like:

pin_function(pinmap->tx_pin, pinmap->tx_function);
pin_function(pinmap->rx_pin, pinmap->rx_function);

if (pinmap->tx_pin != NC) {
    UART_EnableTx(uart_addrs[obj->serial.index], true);
    pin_mode(pinmap->tx_pin, PullUp);
}
if (pinmap->rx_pin != NC) {
    UART_EnableRx(uart_addrs[obj->serial.index], true);
    pin_mode(pinmap->rx_pin, PullUp);
}

I moved the pin_function() calls into the if(!=NC) sections for Tx and Rx as such:

if (pinmap->tx_pin != NC) {
    pin_function(pinmap->tx_pin, pinmap->tx_function);
    UART_EnableTx(uart_addrs[obj->serial.index], true);
    pin_mode(pinmap->tx_pin, PullUp);
}
if (pinmap->rx_pin != NC) {
    pin_function(pinmap->rx_pin, pinmap->rx_function);
    UART_EnableRx(uart_addrs[obj->serial.index], true);
    pin_mode(pinmap->rx_pin, PullUp);
}

This works, so there is a bug in the K64F implementation of serial_api.c

Is this the correct way to log the bug or should I follow another process?

Thanks.

3

for bugs, it’s better to open an issue on github

4

Thanks. Issue submitted on GitHub @ Setting BufferedSerial pin to NC throws runtime assertion · Issue #14353 · ARMmbed/mbed-os · GitHub

5

Hi Mark,

thanks for raising a bug for this. If you also have a solution, we actively encourage fixes supplied by the community as well.

Thanks
Anna

6

Thanks Anna. I’ve submitted a fix on Git and the merge to master has been approved.

As a noob it was a little hard for me to figure out what to do with mbed on Github to make this happen. If you had a guide, even with links to helpful Github KB articles, it would have made the process a little less intimidating and might encourage others to contribute more readily.

1 Like
7

Hi Mark,

thank you for the contribution it is very appreciated. Are you aware of all our documentation ? For example our workflow is documented here Workflow - Contributing | Mbed OS 6 Documentation . We don’t cover how to use GitHub / Git itself as that is a general tool that most open source developers are already aware of and there are a multitude of guides already out there :slight_smile:

Regards
Anna

8

Thanks. No I did not see this as I never thought of myself as a contributor.

There is a section " Guidelines for GitHub pull requests" that looks like it should be useful to others in the same boat. I’m sure I violated a few of these.