0

I am trying to use two serial ports on the STM32 Nucleo-C092RC, but the 2nd serial port (i.e. USART1) is completely silent (USART2 is the default serial port used by STLink/VCP/USB on the C092RC). No output whatsoever.

I am using Arduino IDE version 2.1.1 and Windows 8 (later version of the IDE does not work on Windows 8).

My purpose is to output bytes to an IR module YS-IRTM and print the response code from the IR module on the USB, which uses USART2 via the STLink interface. I seemed to be getting no response on the IR module so I then substituted a TTL-USB converter for the IR module to see whether the data is being sent, and on the TTL-USB converter I am getting nothing. I am getting no stated errors during compiling.

The TTL-USB is connected to Arduino pins D0 and D1, which on the C092RC are Rx and Tx of USART1 (PB7 and PB6). Naturally I crossed the Rx and Tx lines.

The USART2/Serial2 port is connected to the STLink and the output works normally. I am not clear about how to instantiate Serial1; it looks like I have not succeeded. Do I need to declare the pin numbers for Serial1 or are they picked up from the hardware definition? Is there something else I need to declare to get Serial1 fully enabled?

First I created a text file build_opt.h in the sketch folder with the single line:

-DENABLE_HWSERIAL1

and closed the IDE. When I restarted the IDE the new build_opt.h tab appeared and seemed to be included in the compile. No output from the TTL-USB converter connected to Serial1.

I then added the line:

-DPIN_SERIAL1_RX=PB7 -DPIN_SERIAL1_TX=PB6

to build_opt.h but still no output on Serial1 (test print text to each serial port). Serial2 works perfectly.

I also tried define the Serial1 pins at the beginning of the main sketch but that also had no effect.

What am I doing wrong?

Here is the code I am using:

#define PIN_SERIAL1_RX PB7
#define PIN_SERIAL1_TX PB6

uint8_t my_serial_bytes[5]={0xA1, 0xF1, 0x00, 0xFF, 0x45}; 
int incomingByte = 0;   // for incoming serial data


void setup() {
  Serial1.begin(9600);
  Serial2.begin(57600);
}

void loop() {
// code for transmitting
Serial1.write(my_serial_bytes,sizeof(my_serial_bytes));
delay(100);
if (Serial1.available() > 0) {
  // read the response code from YS-IRTM
  incomingByte = Serial1.read();
  delay(10);
  // say what you got
  Serial2.print("Response code: ");
  Serial2.println(incomingByte, HEX);
}
delay(2000);        // delay 2sec
Serial1.println("test print serial1");
Serial2.println("test print serial2");
}
Improve this question

2 Answers 2

Reset to default
1

I have found the solution. My original code was in fact correct, but due to unfamiliarity with the IDE version 2 I had an incorrect setting in the IDE: after selecting the setting "CDC (Generic Serial supercede USART)" both serial links worked perfectly. The test print statement sent to Serial2 printed as before, and the test statement sent to Serial 1 was successfully received by the TTL-USB converter and printed on the PC. I removed the test print statements, reconnected the IR module, and in this case the binary commands were sent successfully to the IR module on Serial1, and the response code from the IR module was received on Serial2.

For the benefit of others who may have this problem, please refer to:

technical reference on using multiple serial ports on Github

According to this source there are three methods by which the extra serial can be instantiated (Serial2 is instantiated on the USB connection by default).

  1. Define the pins in the sketch before the Setup() function, as shown in my original post:

#define PIN_SERIAL1_RX PB7

#define PIN_SERIAL1_TX PB6

  1. Define the pins in a text file named build_opt.h in the same folder as the sketch:

-DENABLE_HWSERIAL1

-DPIN_SERIAL1_RX=PB7 -DPIN_SERIAL1_TX=PB6

In this case if the IDE has already compiled the files you need to force it to compile again by selecting a different download method (you can use a download method that is not connected eg say, JLink, but you have to continue until it declares the error that the JLink is not connected); then set the download link back to the download method you are using (in my case STLink) and compile again.

In my case either method (1) or method (2) worked prefectly (one or the other but not both at the same time!). using build_opt.h has the advantage over the other two methods that SerialEvent will work if you require it - see the page I linked.

(3) The third method cited in the above link is to declare HardwareSerial before the Setup() function:

HardwareSerial Serial1(PB7, PB6);

(where PB7 is Rx and PB6 is Tx; these ports are different according to the MCU and serial port used). This is the same method cited by hcheung in his answer above; however it did NOT work in my case. I do not understand why. It refused to compile, stating that Serial1 had already been defined (even though I had removed both method (1) and method (2) definitions!) I can only assume that somehow there was a conflict in my system somewhere but I don't know why it is picking up an extra definition somewhere. It is NOT because it was using files previously compiled.

Improve this answer
5
  • When you choose the Nucleo-C092RC as the board on Arduino IDE, it pre-defined certain set of configurations for you so that you don't need to do the work on preprocessors and linkers as described on method 1 and 2, this including defined what pins you could used for UART1-TX and UART1-RX. Commented Sep 26 at 1:50
  • You didn't say what does not work on method 3, but I could guess that the compiler/linker complain about the duplicated definitions. When you use methods 3, you don't need the custom build_opt.h and you can remove the lines #define PIN_SERIAL1_RX PB7 and #define PIN_SERIAL1_TX PB6. Commented Sep 26 at 1:52
  • core.a(HardwareSerial.cpp.o):(.bss.Serial1+0x0): multiple definition of "Serial1"; C:\...\sketch\YS-IRTM-infrared-transceiver.ino.cpp.o:(.bss.Serial1+0x0): first defined here collect2.exe: error: ld returned 1 exit status Using library SrcWrapper at version 1.0.1 in folder: C:\...\STMicroelectronics\hardware\stm32\2.11.0\libraries\SrcWrapper Using library USBDevice at version 1.0.0 in folder: C:\...\STMicroelectronics\hardware\stm32\2.11.0\libraries\USBDevice exit status 1 Compilation error: exit status 1 Commented Sep 28 at 11:54
  • Error message above (edited paths to fit character limit). Conditions for receiving this error: (1) delete all contents of build_opt.h; (2) delete both define pin_serial_rx/tx statements; (3) add HardwareSerial Serial1(PB7, PB6) statement; (4) change upload method to JLink to force compiling libraries again, compile. then change uplaod method back again, then compile, receive above error. Commented Sep 28 at 12:03
  • For method 3. Error message above. Conditions for receiving this error: (1) delete all contents of build_opt.h; (2) delete both define pin_serial_rx/tx statements; (3) add HardwareSerial statement; (4) change upload method to JLink to force compiling libraries again, compile. then change uplaod method back again, then compile, receive above error. I checked the whole output and confirmed that it is not using libraries compiled from before for either SrcWrapper or USBDevice. I have no idea where it is getting the multiple definition of Serial1 but it is NOT in either the sketch or build_opt.h Commented Sep 28 at 12:10
0

For ST STM32 Arduino Core (stm32duino), by default, only one Serialx instance is available mapped to the generic Serial name (which typically is the UART2).

To use a second serial port(e.g. UART1), a HardwareSerial object should be declared and instantiated in the sketch before the setup() function:

HardwareSerial Serial1(PB7, PB6); // Rx Tx

void setup() {
  Serial1.begin(9600);
  Serial.begin(57600);
}

BTW, if you are communicating with an IR device, code like Serial1.println("test print serial1"); is useless and not something that an IR transmitter could understand.

Improve this answer
1
  • Many thanks for your answer. For some reason it refused to compile, I don't know why. My original code was correct but I had a wrong setting in the IDE, see below. The test print statement cannot be understood by an IR module, but since I had substituted a TTL-USB device precisely to probe what was going on in Serial1 it was useful not useless. Commented Sep 25 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.