Group Actions
Engagement
  • Author Author: Jan Cumps
  • Date Created: Date Created
  • Views 3922 views
  • Likes 2 likes
  • Comments 16 comments
Related
Recommended

STM32H7B3I - the Development Kit STMod+ Connector and Using UART2

Jan Cumps

I'm selected for the STM32H7B3I-DK -  DISCOVERY KIT road test.

In this part of the review, I try to mount the extra fan-out PCB and use its UART pins.

 

I'll start with a rant. The fan-out expansion board does not fit. It is not possible that STMicroelectronics have tested it.

The i2c Grove connector blocks against the WiFi module. It is not physically possible to plug them together.

image

I'll desolder the i2c connector. But what a shame. Even with he connector off, the fan-out will interfere with the WiFi antenna because it's in the keep-out region.

 

Breaking Out the UART Signals

 

Back to business. I want to use the UART2 of the controller. And that's broken out to that STMod+ connector.

image

 

There are multiple options for the pins 2 and 3. To take care that they are connected to the controller UART2 pads, you connect 2 solder bridges:

SB9 for TX, SB11 for RX.

 

image

 

This is not hard. I used a little single wire chunk. The better way is to use a 0R resistor. You can also try to just bridge the pads with solder.

image

 

 

Adapting the Code to work with UART2

The start point is the project from STM32H7B3I - USB, freeRTOS ,Task Notifications and Interrupts .

You can download the CubeIDE project from there, or try to build from scratch as I did...

 

Maybe you want to disable the UART1 from the previous exercise if you want, but there's no need.

Let's enable UART2.

image

For documentation reasons, I gave the 2 pins a user name.

image

 

Adapt the interrupts in the NVIC properties:

image

 

 

And enable code generation (as we did in the previous post for UART1)

image

 

Generate the code.

 

Write the Code

 

This is exactly the same as in the previous blog, but for UART 2.

I used some compiler defines to make it easy for me to switch betwen UART1 (the USB port) and UART2:

 

I created a pointer hart that points to the UART handle of choice:

 

/* USER CODE BEGIN PTD */
#define USE_UART 2
/* USER CODE END PTD */

#if USE_UART == 1
UART_HandleTypeDef *huart = &huart1;
#endif

#if USE_UART == 2
UART_HandleTypeDef *huart = &huart2;
#endif

 

 

In the freeRTOS UART task, I adapted 1 line of code - where it was &huar1, it's now the huart pointer:

 

void TaskUARTListen(void *argument)
{
// ....
    HAL_UART_Receive_IT(huart, in, buffersize);

 

And in the IRQ handler for UART2, I pasted the same code as I did for UART1 in the previous post:

 

void USART2_IRQHandler(void)
{
  /* USER CODE BEGIN USART2_IRQn 0 */

  /* USER CODE END USART2_IRQn 0 */
  HAL_UART_IRQHandler(&huart2);
  /* USER CODE BEGIN USART2_IRQn 1 */
  BaseType_t xHigherPriorityTaskWoken = pdFALSE;
  configASSERT( xTaskToNotifyatUARTRx != NULL );
  vTaskNotifyGiveFromISR( xTaskToNotifyatUARTRx, &xHigherPriorityTaskWoken );
//  xTaskToNotifyatUARTRx = NULL;
  portYIELD_FROM_ISR( xHigherPriorityTaskWoken );

  /* USER CODE END USART2_IRQn 1 */
}

 

That's it, compile and test.

 

Oh, to test that also the Tx line works, I added these two lines at the start of the program, just before the RTOS scheduler is started:

 

  uint8_t str[] = "*IDN?;";
  HAL_UART_Transmit(huart, str, sizeof(str), 100);

 

Both Tx and Rx work. I've tested both directions.

I use a Bus Pirate to emulate the other side of the communication (it's an excellent protocol test tool), and a Papilio Pro FPGA as logic analyser:

imageimage

 

Related Posts
First Experience with CubeIDE
Create a TouchGFX Project with support for the Designer, CubeIDE and Debugger - Pt 1: Screen Works
Create a TouchGFX Project with support for the Designer, CubeIDE and Debugger - Pt 2: Touch Works
TouchGFX Simple Example: react on a button click
USB, freeRTOS ,Task Notifications and Interrupts
the Development Kit STMod+ Connector and Using UART2
TouchGFX Application Framework: Model, View, Presentation, Message Queue
TouchGFX Application Framework: A Mock GUI - Show Statuses, Switch Screens
TouchGFX Application Framework: MVP and the ModelListener
Write a CubeIDE MX application: Hardware Cryptography with DMA
Parents

  • Nice one.  I’m following along to see how well it goes.  After vacillating somewhat, I had thought about applying for the roadtest for this one as well.  In the end I didn’t because it would just have been a replica of what you are doing which wouldn’t have added any value to anyone.  I’m definitely interested in how well it goes, how easy to develop for and any problems/issues that may become a blocker or just too much hassle.  The problems with the breakout board not fitting properly, and the Arduino headers being the wrong pitch are crazy though.  I would already find it a challenge without adding unnecessary issues into the mix!

Comment

  • Nice one.  I’m following along to see how well it goes.  After vacillating somewhat, I had thought about applying for the roadtest for this one as well.  In the end I didn’t because it would just have been a replica of what you are doing which wouldn’t have added any value to anyone.  I’m definitely interested in how well it goes, how easy to develop for and any problems/issues that may become a blocker or just too much hassle.  The problems with the breakout board not fitting properly, and the Arduino headers being the wrong pitch are crazy though.  I would already find it a challenge without adding unnecessary issues into the mix!

Children