USART gibberish

[beginner3456789]

The USART always sent gibberish even after trying many baudrates and parities.

I adapted the boards.txt and platform.txt to allow using a USB to serial adapter while waiting for a new ST-Link. The adapter uses the CP210x type chip and worked fine to upload the opencm3 bin to the generic STM32f103c board using the stm32flash program. The STM32 embedded bootloader requires 8e1 mode to send the bin to flash. My system is linux64 with kernel 4.10 and arduino 1.8.0.

I modified the ~/Arduino/hardware/arduino_opencm3/stm32/cores/opencm3/Uart.cpp to fix the problem.

Old:
    usart_set_baudrate(usart, baudrate);
    //usart_set_databits(usart, bits);
    //usart_set_stopbits(usart, stopbits);
    //usart_set_parity(usart, parity);
    usart_set_flow_control(usart, USART_FLOWCONTROL_NONE);
    usart_set_mode(usart, USART_MODE_TX_RX);
    rxBuffer.clear();
    txBuffer.clear();
    txRunning=false;
    usart_enable_rx_interrupt(usart);
    usart_enable(usart);

New:
    usart_set_baudrate(usart, baudrate);
    usart_set_databits(usart, HARDSER_DATA_8);    /* fixed */
    usart_set_stopbits(usart, USART_STOPBITS_1);  /* fixed */
    usart_set_parity(usart, USART_PARITY_EVEN);   /* fixed */
    usart_set_flow_control(usart, USART_FLOWCONTROL_NONE);
    usart_set_mode(usart, USART_MODE_TX_RX);
    rxBuffer.clear();
    txBuffer.clear();
    txRunning=false;
    usart_enable_rx_interrupt(usart);
    usart_enable(usart);

The USART databits, stopbits and parity settings were commented out in the original code. That might have left the USART unconfigured and causing the gibberish to be sent. Just adding these values suddenly allowed the USART to communicate correctly. I don't know why the code was at some point commented out and if that might affect anything else like USB for example. I also doubt my fix is the best technique to solve the problem.

The arduino examples now mostly work in my setup (except for the two opencm3 versions). The adc-test.cpp even works directly as adc-test.cpp.ino within the arduino ide and shows a lot of libopencm3 code. That example might be enough for my purposes of experimenting and learning as a beginner with arduino, libopencm3, stm32 and C. I might spend more time with arduino_opencm3 now that serial communication and Serial.println works under my conditions.

[Serasidis]

Thanks @beginner3456789 . Your modification has been included to the master repository.

[beginner3456789]

Wow, that was fast. Please feel free to close this issue. Actually, I am afraid this technique might override a users alternatives for example: Serial.begin(115200,SERIAL_8N1); Serial.begin(115200,SERIAL_8O1); Serial.begin(115200,SERIAL_8N2); Maybe there should have just been defaults set someplace else for the bits, stopbits and parity while uncommenting the lines? I am not experienced enough to do that correctly. At least this works now while not working for any mode at all before with my setup. Thanks.

[Serasidis]

Passing parameters to the Serial initiallization is not implemented yet Serial.begin(115200,SERIAL_8N1) . So, it's good enough for now to use the most common setup 8N1

-EDIT- hm... I think we should set the USART_PARITY_EVEN to USART_PARITY_NONE

[beginner3456789]

The parity NONE should also work. I think many adapters ignore parity. I selected EVEN parity just because the STM32 requires that for the embedded bootloader on the USART only to flash a new bin file. A reset after flashing should cause the adapter to readjust to the new serial stream whatever the mode. Occasionally I need to unplug the STM32 and serial adapter to get back to common ground. Sometimes the stm32flash can execute the new program directly without a reset using the -g flag except I haven't been able to get that to work yet with the arduino_opencm3 bin files anyway so I don't think the EVEN parity is important and NONE should work as well.

[beginner3456789]

Sorry for all the editing of my theories. I don't have the way this works figured out yet. Test results here: usart-test2.txt

I have a lot of experimenting to do still and need to test the USART params more extensively. I have the arduino_opencm3 installed on two computers and this computer works with both of these in Uart.cpp: usart_set_databits(usart, 8); usart_set_databits(usart, 0x400); This is confusing because the other libopencm3 examples use the first choice and I think that is preferred to maintain compatiblity with the rest of libopencm3. Maybe the second choice is overridden by the libopencm3 settings and is set to databits = 9 automatically. So I think my first post should be changed to avoid use of HARDSER_DATA_8 and just use '8' as shown in the first choice above.

Finally, I just discovered the gibberish appears when using parity. I was able to solve this problem when using parity by instructing the picocom to use databits=7 even when arduino_opencm3 was supposed to send databits=8. I now recommend using the default of SERIAL_8N1 so 8 bits are sent and received and no bits are taken away for parity. These numbers are explained in the libopencm3 library source files and in the STM32F1xx reference manual.

[beginner3456789]

Attached are the changes to Uart.cpp enabling the Serial.begin(baud,SERIAL_XXX) params. This has passed all of my tests using a USB to serial adapter on USART1 of a STM32F103c8t6. I have displayed the results using the Arduino monitor and the picocom on /dev/ttyUSB0 with no failures. Please report problems when using other terminals or chips. arduino-opencm3-usart-good.txt

Lessons Learned: Be sure to double check the Arduino preferences.txt settings for serial.parity, serial.databits and serial.stopbits if having problems with gibberish in the Arduino monitor display.