USART3 stops working after code update.

[DTard.1]

I have a motor control board built around the STM32F446RET6.

I was updating code using motor control workbench to alter the control parameters.

After an update, I was no longer able to use the motor control workbench console to communicate with the board through USART3.

Here is the sequence of events that 'broke' the link.

1. I had the motor control working fine. The motor would spin, and motor control workbench was functional and allowed me to monitor speed, make adjustments, etc.
2. The speed was incorrect. I traced that to incorrect motor settings, which I changed.
3. After changing the settings, the motor started up, and the current waveforms were quite good. However, the control shutdown on a speed feedback fault.
4. There are 2 speed 'observers' available in the ST micro package. 1 is PLL based, which I was using, and was clearly superior in the original prototype testing. The alternate was based on an algorithm called 'CORDIC' that I did not have much success with.
5. Since I changed the motor parameters and had good performance, I decided to try the CORDIC observer. The change is made in motor control workbench, used to update CubeMX which then generates the code.
6. Motor performance was worse with CORDIC, so I decided to change back to PLL.
7. When I changed to PLL, I again updated CubeMX so other settings would not change.
8. At this point, I was getting compiler errors in the IDE for parameters that have always been part of the code.
9. Not knowing what else to do, I went back to motor control workbench, and this time instead of an update I generated a fresh .ioc.
10. This new code compiled, but at this point, the serial interface was broken.

Here are the versions of the SW tools I am using:

Motor Control Workbench - 5.4.7

STMCubeMX - 6.3.0

STMCubeIDE - 1.3.0

I have reviewed the USART settings in CubeMX, I everything looks okay to me.

I have a point on the board where I can scope USART3-RX and USART3-TX.

There is definitely activity on RX, but I rarely see any signals on TX.

I also attempted to put a breakpoint in the code for the USART, but this breakpoint never got triggered. So it appears the interrupt routine is not being called.

Any advice on where to look to correct this issue?

[RetroInTheShade]

Hi,

What method are your using for USART TX / RX?

A long shot, but rebuilding can sometimes result in Cube placing the DMA_Init after the associated USARTx_UART_Init()...

Cheers.

[Tesla DeLorean]

Check clocks and pin settings. Perhaps hidden in MSP code file.

Make sure HSE_VALUE define matches your external clock source, as this often leads to baud rates appearing wrong. Look in stm32F4xx_hal_conf.h

Perhaps test sending a 0x55 (U) test pattern in a loop so you can scope the data.

[DTard.1]

I checked into some of these things as best as I can.

First, the UART is set up to be interrupt driven.

I checked to see if DMA_Init was run afterwards, and I did not see DMA_Init

For clocks, I started my code generation using motor control workbench. For the MCU I am using, it has 3 external clock speeds: 8 MHz, 16 MHz and 25 MHz.

I have a 12 MHz crystal for the external clock, so I used 8 MHz.

So, I used the clock setting feature in STMCUbeMX to change the external clock frequency to 12 MHz, and adjusted the prescalers as needed.

Recompiling with the new code did not change anything, still no communication.

As for pin configuration, I noticed that no GPIO initialization has been made for PC10 and PC11, which are the USART3 RX and TX pins I am using.

My next step might be to insert some code to initialize these pins, and see if that solves the problem.

[Tesla DeLorean]

grep or find-in-file the HAL_UART_MspInit() function typically stm32f3xx_hal_msp.c or similar MSP file..

[RetroInTheShade]

If you have the USART configured in your .ioc then it is quite uncommon for Cube to fail to generate the appropriate GPIO config.

To check, cube puts the associated initialisation of the GPIO (and the DMA if enabled) in the function:

HAL_UART_MspInit()

[DTard.1]

Thanks to both of you for these suggestions.

I have found both HAL_UART_MspInit() and HAL_UART_Init() in the file stm32f4xx_hal_uart.c

Neither of these files contain code to initialize the GPIOs.

Below is the code form HAL_UART_MspInit()

I didn't include HAL_UART_Init; it is long and seems to be mostly low level setting of bits, etc.

It does seem bizarre that the I haven't seen the routines to initialize the GPIOs.

Note: I don't see the file stm32f4xx_hal_msp.c in the driver section of my code.

Is it possible that this is the missing piece to the code?

Thank you

Dale

/**

 * @brief UART MSP Init.

 * @param huart Pointer to a UART_HandleTypeDef structure that contains

 *               the configuration information for the specified UART module.

 * @retval None

 */

__weak void HAL_UART_MspInit(UART_HandleTypeDef *huart)

{

 /* Prevent unused argument(s) compilation warning */

 UNUSED(huart);

 /* NOTE: This function should not be modified, when the callback is needed,

          the HAL_UART_MspInit could be implemented in the user file

  */

}

[Tesla DeLorean]

Those​ are some weak functions to allow the linker to complete.

In a more normal setup these would be in an MSP file​, or in your own HAL code for initializing the USART.

Assuming you didn't archive your working code/build..​

[DTard.1]

Unfortunately, no.

I have some older code, that was used to program a Nucleo board in early development.

I had communication working on that prototype.

I don't know my way around ST code that well.

So I am not sure where to look for the MSP files.

I do not have my own code at this time to initialize the USART.

[Tesla DeLorean]

I don't use CubeMX or code generators, they just obfuscate the details.

Here from CubeF4 an example

https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Projects/STM32446E-Nucleo/Examples/UART/UART_Printf/Src/stm32f4xx_hal_msp.c

Might I suggest find a File Manager or Viewer that lets you search files, or some kind of static analysis tool that lets you browse the source, and cross-reference the functions and files. Lot of things integrated into current IDEs. but they do exist external too them and good for understanding structure and relationships in code you didn't write yourself.

[DTard.1]

Yes, thanks, I will see what tools are available I can use.

I ask a colleague for help, he just reported that he got the code working.

I will go through his steps and see what happens for me.

It sounds like it requires the correct version of CubeIDE paired with the version of CubeMX I use.

[DTard.1]

So, I tried following the steps my colleague used.

I have had no success.

He was able to get communication working once, but when changing or adjusting something, the problem seems to reoccur.

I tried compiling with low level drivers vs HAL, the code would not even compile.

I am going to try Tesla DeLorean's suggestion, look at the code example provided, and see if what I can get that working.

Do you compile your code with STM32CubeIDE, or do you use another tool?

[Tesla DeLorean]

I predominantly use Keil, occasionally gnu/gcc with make, and I don't use code generators like CubeMX