Skip to main content
Neiliow
Associate II
April 12, 2023
Question

How do I get the USART to work on an STM32C011?

  • April 12, 2023
  • 3 replies
  • 3104 views

I am relatively new to using the STM32 family and I am trying to use the USART on a STM32C011J4M6 device without success.

Initially I am just trying to send out a single character using the lines

 uint8_t TxData[] = {'@'};
 HAL_UART_Transmit(&huart1, TxData, 1, 10);

 after USART1 has been set up by CubeMX.

When it runs however, as soon as it tries to write to the Transmit Data Register, the processor resets. I have verified where it is going wrong by stepping through the disassembly - all the registers seem to be set up correctly but immediately on executing the STR instruction to write the character to 0x40013828 (USART1 TDR) it jumps to the reset handler.

I have been using STM32F042K6 and other devices up until now and the same code behaves correctly in those, exactly as expected.

I'm not sure what I am doing wrong so can anyone point to what it might be? If I remove the HAL_UART_Transmit() then the rest of the code runs (although it is just toggling a GPIO pin at the moment).

Thanks for any advice.

This topic has been closed for replies.

3 replies

Foued_KH
ST Employee
April 12, 2023

Hello @Neiliow​ ,

uint8_t TxData[] = "@";
 HAL_UART_Transmit(&huart1, TxData, 1, 10);

Foued

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Neiliow
NeiliowAuthor
Associate II
April 12, 2023

Thanks Foued but that's not where the problem is. The '@' character is getting to the correct place and it fails when it is trying to write that into the Transmit Register. I can trace the disassembled program right up to that point so it is getting the character to send out. The problem happens when I write to TDR, it doesn't matter what data I try to write to it - '@' or anything else.

Neil

Tesla DeLorean
Guru
April 12, 2023

The processor shouldn't reset.

Double check board, make sure the UART TX pin isn't connected to anything that would reset the system, or cause a short or brown-out type event.​

C​ode lacks any broader context.

I​s this a chip with low pin count or pins bonded to multiple IO outputs or function?

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
Neiliow
NeiliowAuthor
Associate II
April 12, 2023

The Tx pin is just connected to an oscilloscope and the chip is in a breadboard with the only connections being its power rails, an LED on a GPIO pin and the ST-Link on the SWD pins.

There isn't much code at the moment other than what was generated by Cube MX. The chip is an 8-pin device so the pins have multiple functions but only USART1 and SWD are enabled.


_legacyfs_online_stmicro_images_0693W00000bhxXhQAI.png 

However you have got me wondering now - the TxD pin is also shared with nRST so maybe that is what's happening. When TxD goes low it is seeing that as a reset. I'll have a look into it. Thanks for the hint.

Tesla DeLorean
Guru
April 12, 2023

Yes, super low pin count device. Watch what else is bonded to pin.

Attach minimal / buildable project demonstrating issue as a ZIP file.​

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
Neiliow
NeiliowAuthor
Associate II
April 12, 2023

OK, here you go...

This will demonstrate the problem, resetting as soon as it tries to send data on USART1.

I can't find anything about how to forcibly disable the reset function from that pin. I assumed it would be done if the pin was assigned as TxD for the USART.