cancel
Showing results for 
Search instead for 
Did you mean: 

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

Neiliow
Associate II

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.

7 REPLIES 7
Foued_KH
ST Employee

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
Associate II

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

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 Venmo
Up vote any posts that you find helpful, it shows what's working..
Neiliow
Associate II

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.

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 Venmo
Up vote any posts that you find helpful, it shows what's working..

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.

Update - I found in the Cube Programmer a setting to disable the reset input on that pin
_legacyfs_online_stmicro_images_0693W00000bhxklQAA.pngand setting it to 2 as above stops the processor from resetting on a Tx.

I still can't see any data coming out of the pin yet but that is probably a different problem. I think it's closer to working than it was before.

Thanks for your inspiration!