[STM32F1] Serial features inconsistent

[adbam]

Description

• Type: Enhancement | Question

---

Target
NUCLEO_F103RB
BLUEPILL_F103C8
DISCO_F100RB

---

Inconsistency

Inconsistent device features on STM32F1 devices in targets.json file.

NUCLEO_F103RB states that it has SERIAL and SERIAL_ASYNCH
BLUEPILL_F103C8 and DISCO_F100RB only have SERIAL

As far I can see, all resides on serial_api.c code, which implies they should have the same features. Also there is already code for SERIAL_FC and the F1xx family is the only one from ST that lacks support for it. However there are no RTS/CTS definitions in PeripheralPins.c, but is that all it needs to add SERIAL_FC to these devices?

---

Enhancement

All STM32F1 devices have the same features

[jeromecoutant]

Hi
ST is not the owner of these 2 platforms (BLUEPILL_F103C8 and DISCO_F100RB), and then can not validate SERIAL_ASYNCH feature.
But you're right, HAL updates done for NUCLEO_F103RB should be also applicable for your targets, don't hesitate to push new pull requests to update targets.json file.
Regards,

[adbam]

Thanks, I wasn't aware DISCO_F100RB isn't supported either.
Can you tell me about SERIAL_FC support for NUCLEO_F103RB?

[jeromecoutant]

ST supported platforms:
https://developer.mbed.org/platforms/?pvend=10

About NUCLEO_F103RB, yes it is supporting HW flow control:
http://www.st.com/resource/en/reference_manual/cd00171190.pdf

[0xc0170]

cc @zgoda @dinau

[adbam]

Thanks @bcostm
today I tried to enable RTS on Nucleo_F103RB but without luck.

Modifications

I'm working on mbed-os (fc1f439) and modified:
targets.json adding "SERIAL_FC" to NUCLEO_F103RB entry

targets/TARGET_STM/TARGET_STM32F1/PeripheralPins.h by adding
extern const PinMap PinMap_UART_RTS[];
extern const PinMap PinMap_UART_CTS[];

Testcode:

#include "mbed.h"
#include "mbed_config.h"

Serial pc(PA_2, PA_3, 9600);

int main() {
    pc.format(8, SerialBase::None, 1);
    pc.set_flow_control(SerialBase::RTS, PA_1);

    while(1){
        wait(1);
        pc.putc(0x55);
    }
}

Measuring with my LA it shows that PA_2 is sending 0x55, but PA_1 stays low.
Is my test wrong, or are more modifications needed?

[bcostm]

Just in case you need also to add the RTS/CTS pins in the PeripheralPins.c file. But all of this are already in the master branch, did you try it ?

I found this test program in mbed tests. You can maybe adapt it and check if ok ? The LED should blink when you receive a falling edge on the RTS pin.

#include "mbed.h"

#define UART_TX             PA_2
#define UART_RX             PA_3
#define FLOW_CONTROL_RTS    xxx
#define FLOW_CONTROL_CTS    xxx
#define RTS_CHECK_PIN       xxx

Serial pc(UART_TX, UART_RX);

#ifdef RTS_CHECK_PIN
InterruptIn in(RTS_CHECK_PIN);
DigitalOut led(LED1);
static void checker(void) {
  led = !led;
}
#endif

int main() {
    char buf[256];

    pc.set_flow_control(Serial::RTSCTS, FLOW_CONTROL_RTS, FLOW_CONTROL_CTS);
#ifdef RTS_CHECK_PIN
    in.fall(checker);
#endif
    while (1) {
        pc.gets(buf, 256);
        pc.printf("%s", buf);
    }
}

[adbam]

I will try the testcode in a few days when I can arrange some time.

Currently I'm working on master head and checked out after your commit for PeripheralPins.c. But at this stage my compiler tells me the function set_flow_control is not defined, and the same with the RTS and CTS definitions. Thats why I had to modify PeripheralPins.h and targets.json as well.

I was hoping these two filechanges would be enough to create a PR to enable flow control on F1 devices, but I couldn't see an effect on my RTS pin.

[adbam]

Ok, I think I got it. Coming from Linux I falsely assumed I could use RTS to manage half duplex switch for RS485. I got stuck in the datasheet at section 27.3.14 where RTS behaviour is defined and it's different from my expectations. Finding this appnote made it clear, RTS can not be misused for half duplex switching.
http://www.st.com/content/ccc/resource/technical/document/application_note/52/57/b8/e4/08/38/43/cd/CD00249778.pdf/files/CD00249778.pdf/jcr:content/translations/en.CD00249778.pdf

Either way, RTS and CTS need to be defined to enable them for userspace. My approach:

diff --git a/targets/TARGET_STM/TARGET_STM32F1/PeripheralPins.h b/targets/TARGET_STM/TARGET_STM32F1/PeripheralPins.h
index 0a523c6..93ce0c5 100644
--- a/targets/TARGET_STM/TARGET_STM32F1/PeripheralPins.h
+++ b/targets/TARGET_STM/TARGET_STM32F1/PeripheralPins.h
@@ -51,6 +51,8 @@ extern const PinMap PinMap_PWM[];
 
 extern const PinMap PinMap_UART_TX[];
 extern const PinMap PinMap_UART_RX[];
+extern const PinMap PinMap_UART_RTS[];
+extern const PinMap PinMap_UART_CTS[];
 
 //*** SPI ***
 
diff --git a/targets/targets.json b/targets/targets.json
index b70bbcc..2a8065a 100644
--- a/targets/targets.json
+++ b/targets/targets.json
@@ -708,7 +708,7 @@
         "inherits": ["Target"],
         "detect_code": ["0700"],
         "macros": ["TRANSACTION_QUEUE_SIZE_SPI=2"],
-        "device_has": ["ANALOGIN", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
+        "device_has": ["ANALOGIN", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
         "release_versions": ["2", "5"],
         "device_name": "STM32F103RB"
     },

[bcostm]

I don't know what happened the other day, I was sure to have seen the SERIAL_FC enabled for this board in the master branch. I checked again ant it was not the case... Anyway I have sent a PR that corrects it.