cancel
Showing results for 
Search instead for 
Did you mean: 

32F769IDISCOVERY UART7 usage

Joerg Wagner
Senior III
Posted on November 08, 2017 at 13:41

I selected the 32F769IDISCOVERY board in CubeMX.

Why is UART7 in CubeMX disabled?

The pins in the conflicts list are not mapped or active.

For my app I need the Arduino Pin D3 which is UART7_RX.

I studied the schematics and do not find any conflict with other devices.

When I force to use PF6 for RX7 and PF7 for TX7 the UART7

can be activated in CubeMX.

But my app does not receive a character in the callback function (IT is used).

Thank you.

1 ACCEPTED SOLUTION

Accepted Solutions
Joerg Wagner
Senior III
Posted on November 08, 2017 at 22:37

I think I solved it and this is a kind of embarrassing: The device, a barcode scanner, was not connected 100% with his RJ45 connector. Sometimes data were received and sometimes not.

@

Turvey.Clive.002

: Thank you for your time.

But the issue with CubeMX still exists, not a big problem - just a little spot.

View solution in original post

4 REPLIES 4
Posted on November 08, 2017 at 14:40

I would expect this to be workable PF6 AF8 UART7 (D3)

Check the clocks and pin initialization

Might try later, have one of these boards on the bench currently.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Joerg Wagner
Senior III
Posted on November 08, 2017 at 16:21

Hello Clive!

For the CubeMX issue you do not need a board.

I forgot to mention some things:

- USART1, UART5 and USART6 are in use as well (I need them all)

- STemWin with BSP (just SDRAM, no SD right now)

- LwIP (NO_SYS=1)

  /* USER CODE END UART7_MspInit 0 */

    __HAL_RCC_UART7_CLK_ENABLE();

    /**UART7 GPIO Configuration

    PF6     ------> UART7_RX

    PF7     ------> UART7_TX

    */

    GPIO_InitStruct.Pin = UART7_RX_Pin; // |UART7_TX_Pin;    not needed

    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;

    GPIO_InitStruct.Pull = GPIO_PULLUP;

    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;

    GPIO_InitStruct.Alternate = GPIO_AF8_UART7;

    HAL_GPIO_Init(GPIOF, &GPIO_InitStruct);

    /* UART7 interrupt Init */

    HAL_NVIC_SetPriority(UART7_IRQn, 0, 0);

    HAL_NVIC_EnableIRQ(UART7_IRQn);

  /* USER CODE BEGIN UART7_MspInit 1 */

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)

{

    if (huart==&huart7) {

      ...

      HAL_UART_Receive_IT(&huart7, &rx7_ch, 1);

   }

   ...

}

in main()

MX_UART7_Init();

   ...

   HAL_UART_Receive_IT(&huart7, &rx7_ch, 1);

It worked sometimes, but not everytime. It means

if (huart==&huart7)

is never true.

I have the problem (no UART7 interrupts or a simple HAL_UART_Receive(&huart7, &rx7_ch, 1, 0x100); ) after calling

GUI_Init();

and I don't know what it does exactly. And yes, I tried to call MX_UART7_Init(); after GUI_Init();

But it worked for a time, there is hope...

- Joerg -

Joerg Wagner
Senior III
Posted on November 08, 2017 at 22:37

I think I solved it and this is a kind of embarrassing: The device, a barcode scanner, was not connected 100% with his RJ45 connector. Sometimes data were received and sometimes not.

@

Turvey.Clive.002

: Thank you for your time.

But the issue with CubeMX still exists, not a big problem - just a little spot.

Posted on November 08, 2017 at 22:00

>>

For the CubeMX issue you do not need a board.

Except I'm not using CubeMX, and have no control of its development/function - Don't work for ST.

I've confirmed that UART7 will receive data from Arduino D3 (PF6 UART7_RX) on the STM32F769I-DISCO, so hardware is viable/functional.

For the experiment I use USART1 PA9/PA10 to output data via the VCP, and proved a GPS shield either on D0 (PC7 USART6_RX) or 

D3 (PF6 UART7_RX) was usable.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..