cancel
Showing results for 
Search instead for 
Did you mean: 

STM32C011J6M6 single-wire USART (STM32CubeMX/IDE getting-started question)

wb0gaz
Senior

Need getting-started help with STM32C011J6M6 MCU and USART1 in single-wire Async mode (using STM32Cube toolchain and C language.)

The hardware configuration is just  the STM32C011J6M6 MCU (8-pin SOIC package) with one pin (pin 1) pulled up (4.7K to 3.3V). Intent is to use this in single-wire Async mode to communicate with outside world. All other MCU pins have similar pull-up resistors but are not otherwise connected. Power to the MCU for this test is furnished by the STLINK device. The test is using programmed I/O (no DMA,  no interrupts.) The test program solely is written to experiment with the USART1 in single-wire mode on this device; there  are no other aspects being tested or included.

 
Tools in use:
IDE 1.19.0
MX 6.15.0
PROG 2.10.0
 

Used STM32CubeMX to generate code template (targeting STM32CubeIDE), STM32CubeIDE to build the example (C-language) program, and STM32CubeProgrammer to push the resulting (elf) binary to the device using STLINK attached to the  SWCLK/SWDIO and power pins.

When running, expected result is that async bytes will appear on pin 1 (active low, open drain). Actual result is that pin 1 remains held high by it's pull-up resistor.

I previously checked hardware using another short  program (same tools) to set the pin as GPIO (open drain) and then toggled the pin high/low (with delay in loop) to verify electrical behavior.

Four screen grabs from STM32CubeMX are attached, as is the main.c program being used  for this test (a single ZIP file contains the five small files.)

 

My questions (other than a plea for help getting started!) are this:

 

1. Is something (during initialization) not being enabled that should be enabled? (that is, does the code generated by STM32CubeMX expect the user to amend it to enable or power-up a key internal peripheral (such as Clock, GPIO or the USART)? (recall that I used the same method to verify GPIO output toggling is possible with no changes to the MX generated code other than adding the "toggle the pin" code.)

2. Does single-wire (USART) mode work when the CPU pin only has TX capability (for that peripheral)? Do I need to add/specify anything about the RX pin (which I believe  is not used nor enabled when in single-wire mode)? Pin 1 offers PB7/PC14-OSCX_IN, I am using PC14 (only) which supports USART1_TX, TIM1_ETR, TIM1_BKIN2, IR_OUT, USART2_RTS_DE_CK, TIM17_CH1, TIM3_CH2, I2C1_SDA, EVENTOUT). Note that while I am using single-wire mode (which I gather is based on a configuration of USART1_TX, the pin does not offer USART1_RX capability.

3. Are the instructions HAL_HalfDuplex_EnableReceiver(&huart1); and HAL_HalfDuplex_EnableTransmitter(&huart1); actually required in this use case? My prior work (bare-metal style) with STM32F103 and single-wire USART mode didn't have any sort of enable instructions involved; once configured the USART worked as expected (for both transmit and receive) provided that the application "knew" when it was allowed to send data.

Attached (below) is a single ZIP file (the  maximum attachments is 3, my file count is 5) containing four screen captures from STM32CubeMX and one copy of the generated main.c (with a few lines of application code added), as a .txt file.

 

Happy to provide any clarifying information as needed!

Thank you,

Dave

(Virus scan in progress ...)
0 REPLIES 0