STM32F207VGT6 UART configuration error

[liszto]

my UART settings are as follows:

void USART_Configuration(EUartCom uartCom)
{
    USART_Config(uartCom, COM_BAUDRATE[uartCom]);
}

void USART_Config(EUartCom uartCom, uint32_t baudrate)
{
    USART_DeInit(COM_USART[uartCom]);
    GPIO_InitTypeDef GPIO_InitStructure;
    // DE:
    GPIO_InitStructure.GPIO_Pin = COM_DE_PIN[uartCom];
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
    GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
    GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_DOWN;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_Init(COM_DE_PORT[uartCom], &GPIO_InitStructure);
    GPIO_ResetBits(COM_DE_PORT[uartCom], COM_DE_PIN[uartCom]);

    // TX:
    GPIO_InitStructure.GPIO_Pin = COM_TX_PIN[uartCom];
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_25MHz;
    GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
    GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
    GPIO_Init(COM_TX_PORT[uartCom], &GPIO_InitStructure);

    // RX:
    GPIO_InitStructure.GPIO_Pin = COM_RX_PIN[uartCom];
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
    GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
    GPIO_Init(COM_RX_PORT[uartCom], &GPIO_InitStructure);

    // AF:
    GPIO_PinAFConfig(COM_TX_PORT[uartCom], COM_TX_PIN_SOURCE[uartCom], COM_AF[uartCom]); // TX
    GPIO_PinAFConfig(COM_RX_PORT[uartCom], COM_RX_PIN_SOURCE[uartCom], COM_AF[uartCom]); // RX

    // USART
    USART_InitTypeDef USART_InitStructure;
    USART_InitStructure.USART_BaudRate = baudrate; 
    USART_InitStructure.USART_WordLength = COM_WORD_LENGTH[uartCom];
    USART_InitStructure.USART_StopBits = COM_STOP_BITS[uartCom];
    USART_InitStructure.USART_Parity = COM_PARITY[uartCom];
    USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
    USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
    USART_Init(COM_USART[uartCom], &USART_InitStructure);

    // RXNE Enable
    USART_ITConfig(COM_USART[uartCom], USART_IT_RXNE, ENABLE);
    // IDLE Enable
    USART_ITConfig(COM_USART[uartCom], USART_IT_IDLE, ENABLE);
    // USART
    USART_Cmd(COM_USART[uartCom], ENABLE);
}

UART setting by getting defined value.

uint32_t COM_BAUDRATE[COMn] = {76800, 57600, 38400, 115200};

    USART_Configuration(COM0);
    USART_TX_DMA_Init(COM0);
    USART_SetDE(COM0, serialRx);
    
    USART_Configuration(COM1);
    //USART_Config(COM1, 57600);
    USART_TX_DMA_Init(COM1);
    USART_SetDE(COM1, serialTx);
    
    USART_Configuration(COM2);
    USART_TX_DMA_Init(COM2);
    USART_SetDE(COM2, serialTx);

At this time, 'USART_Configuration' is not set,

but 'USART_Config(COM1, 57600)' is operate OK. ;(

Why is this happening?

This code(USART_Configuration) works on STM32F207VG 144pin is OK, but does't work on 100pin chip.

USART1, 3 is OK.
USART2 is problem;

[waclawek.jan]

What is this based on, SPL?

I'm not sure what's the problem here, let's assume this: 

> USART1, 3 is OK.
> USART2 is problem;

Start by reading out and checking/posting the USART2 and relevant GPIO registers content. You may want to compare them to the working USARTs' registers. You may also want to debug the functions by single-stepping them and observing the values of their variables and parameters they are passing around.

JW

[Andrew Neil]

---

@liszto wrote:

At this time, 'USART_Configuration' is not set,

---

What do you mean by that?

How do you determine that it is "not set" ?

Have you tried stepping in the debugger to see what's happening?

 

How to write your question to maximize your chances to find a solution

[Saket_Om]

Hello @liszto 

As @waclawek.jan  suggested, you can set a breakpoint inside USART_Configuration() when it is called with USART_Configuration(COM1); and inspect the values of the variables at that point.

[Ozone]

> What is this based on, SPL?

Very much looks like it, yes.

A common mistake when re-using SPL code, especially this UART init routines, is to neglect the review of the RM.
The UARTs/USARTs themselves are on different busses (APB1, APB2), and the respective RCC enable code often must be adapted as well. Exactly what I miss  in the provided snippets.

[waclawek.jan]

Isn't there the same "magic" built into SPL as in Cube/HAL, which deciphers the APB clock for given peripheral automagically from reading out the RCC dividers?

Btw. USART1 is at APB2 whereas both USART2 and USART3 are at APB1, so that doesn't quite explain the problem, as I understand it.

JW

[Ozone]

> Isn't there the same "magic" built into SPL as in Cube/HAL, which deciphers the APB clock for given peripheral automagically from reading out the RCC dividers?

At least not the versions I have ever seen.
They all simply call either RCC_AHBPeriphClockCmd(), RCC_APB1PeriphClockCmd(), or RCC_APB2PeriphClockCmd().

But many of the UART (and other peripheral) access functions are coded that way in the SPL, in lots of abstruse lines of code.

> Btw. USART1 is at APB2 whereas both USART2 and USART3 are at APB1, so that doesn't quite explain the problem, as I understand it.

Yes, the problem could be elsewhere.
The given code is littered with the SPL "stmxxx_discover.h" macros for ports and pins which are hard to decode.
I would step through the initialisation and check the peripheral register settings.

If I reuse SPL code for my projects, this unreadable stacked-macro bloat is the first I remove.

[Andrew Neil]

---

@Ozone wrote:

I would step through the initialisation and check the peripheral register settings.

---

Seconded - I find that's a good way to see what SPL or HAL actually does in the end.

[Ozone]

> This code(USART_Configuration) works on STM32F207VG 144pin is OK, but does't work on 100pin chip.

I didn't catch this before.

You need to get the F407 datasheet, and check the "Pinout" section if those GPIOs are actually routed to the pins you expect, for both the 144 pin and 100 pin package. Having recently compared two F303 variants and two C031 variants with various pin counts, I can assure you pin assignments differ.

[liszto]

Thank you for your interest in this question.
The meaning of my question is that the two functions are configured with the same action and "UART is not set depending on the call".

USART_Config(uartCom, COM_BAUDRATE[uartCom]);
When calling a function, it works by applying the defined baudrate,
It is an abnormal behavior that works when directly applying a constant value.

What's interesting is that there are another situations where the setup doesn't work depending on the call order.

RCC and NVIC settings are meaningless as they have already been done at the top,
PinMap definition according to Chip is also confirmed.