stm32mp157 (discovery kit) usart3 not starting from A7
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-05-08 08:14 AM
I am using stm32mp157d from stm32mp1 dk1 to work on an embedded project.
When I boot bare-metal from A7, I have no trouble to read and write to UART 4, however I run into a wall when I try to user UART 7 or USART3.
The HAL library works for UART4, so I do not believe that the problem lies there.
That been said, there seem to be a mismatch in the documents about the pins of USART3.
In the document Discovery kits with increased-frequency 800 MHz STM32MP157 MPUs (UM2637) It is stated that USART3 is at CN2, physical pin 8 for TX and pin 10 for RX (9 used for ground) with their in-code name B10 and B12 respectively.
In the document Datasheet - STM32MP157A/D under Table 8Alternate function AF0 to AF7, USART3_TX appears as PD8, PC10 , and PB10 USART3_RX appears as PD9, PC11, and PB11.
So far, I have tried to start USART3 without init any GPIO, trying port b8, b10 , b11 ,c10, c11, D8, D9. I tried those ports in low and high freq.
Please help me understand which ports do I need to assign as USART3, as currently nothing output nor input from port 8 and 10 of the GPIO pins at the discovery kit.
snippet of code from the GPIO init:
static void MX_GPIO_Init(void)
{
GPIO_InitTypeDef GPIO_InitStruct = {0};
/* GPIO Ports Clock Enable */
__HAL_RCC_GPIOB_CLK_ENABLE();
__HAL_RCC_GPIOD_CLK_ENABLE();
__HAL_RCC_GPIOZ_CLK_ENABLE();
__HAL_RCC_GPIOC_CLK_ENABLE();
__HAL_RCC_GPIOH_CLK_ENABLE();
__HAL_RCC_GPIOA_CLK_ENABLE();
__HAL_RCC_GPIOF_CLK_ENABLE();
__HAL_RCC_GPIOG_CLK_ENABLE();
GPIO_InitStruct.Pin = GPIO_PIN_10;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
GPIO_InitStruct.Alternate = GPIO_AF7_USART3;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_12;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
GPIO_InitStruct.Alternate = GPIO_AF8_USART3;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
}
snippet of code of UART init:
huart3.Instance = USART3;
huart3.Init.BaudRate = 115200;
huart3.Init.WordLength = UART_WORDLENGTH_8B;
huart3.Init.StopBits = UART_STOPBITS_1;
huart3.Init.Parity = UART_PARITY_NONE;
huart3.Init.Mode = UART_MODE_TX_RX;
huart3.Init.HwFlowCtl = UART_HWCONTROL_NONE;
huart3.Init.OverSampling = UART_OVERSAMPLING_16;
huart3.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
huart3.Init.ClockPrescaler = UART_PRESCALER_DIV1;
huart3.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
if (HAL_UART_Init(&huart3) != HAL_OK)
{
return -1;
}
if (HAL_UARTEx_SetTxFifoThreshold(&huart3, UART_TXFIFO_THRESHOLD_1_8) != HAL_OK)
{
return -1;
}
if (HAL_UARTEx_SetRxFifoThreshold(&huart3, UART_RXFIFO_THRESHOLD_1_8) != HAL_OK)
{
return -1;
}
if (HAL_UARTEx_DisableFifoMode(&huart3) != HAL_OK)
{
return -1;
}
return 0;
- Labels:
-
STM32MP15 Lines
-
UART-USART
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-05-13 07:10 AM
Hi,
Notice that we did not support any Cortex-A7 HAL for STM32MP15 products.
I see no mismatch between documents, I confirm that for USART3 on STM32MP157D-DK1 board you should use:
- USART3_TX ==> PB10-AF7 ==> GPIO14 ==> CN2-8
- USART3_RX ==> PB12-AF8 ==> GPIO15 ==> CN2-10
Any HAL function error return ?
Are you able to dump USART3 registers (base address 0x4000F000) ?
When you say no output, is there no valid data or no signal at all (even at wrong baudrate, seen with oscilloscope ) ?
Maybe issue on USART3 settings in RCC (USART35SRC and USART3EN)
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-05-15 02:04 AM
There are no Errors from the HAL functions, only hal_bussy when I try to write.
When I say there is no output, I mean no signal in a oscilloscope.
Thank you for bringing up USART3EN, the setting there was wrong, but even fixing it did not help.
When dumping USART3 base (mapped to 0x4000F000 in HAL, so mapped correctly) I have noticed a strange behavior:
Dumping UART3 base:
CR1: 0x00000000.
CR2: 0x00000000.
CR3: 0x00000000.
BRR: 0x00000000.
GTPR: 0x00000000.
RTOR: 0x00000000.
RQR: 0x00000000.
ISR: 0x0C000000.
ICR: 0x00000000.
RDR: 0x00000000.
TDR: 0x00000000.
PRESC: 0x00000000.
HWCFGR2: 0x41000000.
HWCFGR1: 0x11111104.
VERR: 0x32000000.
IPIDR: 0x30003100.
SIDR: 0x10DD5C3A.
None of the control register is updated!
for comparison here is uart 4:
Dumping UART4 base:
CR1: 0xD0000002.
CR2: 0x00000000.
CR3: 0x00000000.
BRR: 0xC2200000.
GTPR: 0x00000000.
RTOR: 0x00000000.
RQR: 0x00000000.
ISR: 0x09000680.
ICR: 0x00000000.
RDR: 0x00000000.
TDR: 0x03000000.
PRESC: 0x00000000.
HWCFGR2: 0x40000000.
HWCFGR1: 0x01101104.
VERR: 0x32000000.
IPIDR: 0x30003100.
SIDR: 0x10DD5C3A.
Even after copying I directly the output of usart3 is the same:
Dumping UART3 base:
CR1: 0x00000000.
CR2: 0x00000000.
CR3: 0x00000000.
BRR: 0x00000000.
GTPR: 0x00000000.
RTOR: 0x00000000.
RQR: 0x00000000.
ISR: 0x0C000000.
ICR: 0x00000000.
RDR: 0x00000000.
TDR: 0x00000000.
PRESC: 0x00000000.
HWCFGR2: 0x41000000.
HWCFGR1: 0x11111104.
VERR: 0x32000000.
IPIDR: 0x30003100.
SIDR: 0x10DD5C3A.
This should not be the case anyway as the HAL suppose to write the configuration to the register.
The copy code snippet:
USART3->CR1 = UART4->CR1;
USART3->CR2 = UART4->CR2;
USART3->CR3 = UART4->CR3;
USART3->BRR = UART4->BRR;
USART3->HWCFGR2 = UART4->HWCFGR2;
USART3->HWCFGR1 = UART4->HWCFGR1;
It is clear from the dump that something is preventing (there is no interrupt that jump so not the mmu) the write or for some reason the memory is read only?
As far as I am aware, I am booting the basic boot (non-secure), and the SPL is not suppose to block this memory region in any way.
Am I mistaken in my assumption of secure area during boot?
Is it a mater of timing, where the register needs to be updated before changing anything in the RCC?
Or is there something else completely that I am missing?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-05-15 02:55 AM
Hi @Amit_Bl
as already says, we did not support bare-metal nor SPL, so I cannot help much more.
You should debug your MMU, ETZPC and clock settings.
Regards