2017-05-01 06:03 PM
I am trying to use the Nucleo-F411RE and connect to a UART device. As started, I am using the example from STM32Cube 'C:\stm32\STM32Cube_FW_F4_V1.15.0\Projects\STM32F411RE-Nucleo\Examples\UART'
I can see the message send to external UART device (terminal) by the 'RX' pin on ST-Link board.
Now, I try to map it to different PIN, so change the following in file
#if 0
#define USARTx_TX_PIN GPIO_PIN_2 // Original setting#define USARTx_RX_PIN GPIO_PIN_3#else#define USARTx_TX_PIN GPIO_PIN_8#define USARTx_RX_PIN GPIO_PIN_9#endifWhen I connect to D7 on CN9 on the board, I do not see the print out message.
Is there any limitation in which IO pin I could use ?? or there are additional code changes to configure the PINs, like Input/Output in the example code.
Are the Arduino pin are mapped to mcu by default, or some SB bridge need to be changed ?
Thanks for advice
2017-05-01 06:42 PM
Also, as for testing, I tried switching from USART2 to USART1 but did not work either....
Is there any limitation on what USART being used on certain board ??
Or I have missed some hidden default setting in the example..
#if 0
#define USARTx USART2#define USARTx_IRQ USART2_IRQn#define USARTx_IRQHandler() USART2_IRQHandler()#define USARTx_CLK_ENABLE() __HAL_RCC_USART2_CLK_ENABLE();#define USARTx_FORCE_RESET() __HAL_RCC_USART2_FORCE_RESET()#define USARTx_RELEASE_RESET() __HAL_RCC_USART2_RELEASE_RESET()#define USARTx_TX_AF GPIO_AF7_USART2#define USARTx_RX_AF GPIO_AF7_USART2#else#define USARTx USART1#define USARTx_IRQ USART1_IRQn#define USARTx_IRQHandler() USART1_IRQHandler()#define USARTx_CLK_ENABLE() __HAL_RCC_USART1_CLK_ENABLE();#define USARTx_FORCE_RESET() __HAL_RCC_USART1_FORCE_RESET()#define USARTx_RELEASE_RESET() __HAL_RCC_USART1_RELEASE_RESET()#define USARTx_TX_AF GPIO_AF7_USART1#define USARTx_RX_AF GPIO_AF7_USART1#endif2017-05-01 06:58 PM
>>
Are the Arduino pin are mapped to mcu by default, or some SB bridge need to be changed ?
PA2/PA3 share functionality with the VCP from the ST-LINK this can potentially cause some conflicts, the NUCLEO-144 and DISCO boards seem to have done a better job.
PA8 is connected to a USART? You sure about that, check the data sheet for the chip. Also remember the 401/411 being short changed on USARTs
PA9 (D8) is USART1_TX, PA10 (D2) is USART1_RX
I've done hybrid stuff with the NUCLEO-64 boards using USART2_TX PA2 (D1) as a common output (in input to shields) and use USART1_RX PA10 (D2) to get the data back in.
2017-05-01 09:00 PM
Data sheet for your part
Review Table 9
2017-05-02 09:24 AM
Based on your reply and info from Datasheet, STM GPIO design are mapped to fixed pins with ability to alternate functionality only, correct ?
PA9 : USART1_TX or I2C3_SMBA, etc
PA10 : USART1_RX or TIM1_CH3, etc
What I am trying is connecting to a external 3G-module for testing before initial board available.
Now, I am clear, thanks. This is first time I use the STM32, previously I used other MCU which allow mapping to any port pin for any purpose
2017-05-02 09:49 AM
Here the choices are finite rather than being a cross-bar switch, and a software USART while potentially viable is generally avoided. In many respects the NUCLEO-144 is a better platform, a lot easier to inject 7VDC VIN to power board and modem.
Probably want 4G/LTE, 3G is being deprecated in North-America
2017-05-02 03:13 PM
This is exactly what I need to do. I will be using the new ST SensorTile (STM32L4) and connect to Telt too.
Since HW not available at the moment, I am using the NUCLEO-F411 & SIMCOM to develop a Serial driver for UART port.
I finally able to communicate with Putty through USART1 (at 115200, 8-bit, no flow control). Send & receive OK while receive running IRQ to put UART data into circular buffer.
However, problem come in again when connecting to SIMCOM module using AT command.
on response (Uart RX) always missing the first 2 bytes. e.g.
--> 'A' 'T' (CR)(LF)
<-- 'O' 'K'
(CR)(LF)
only CR and LF being received by USART1 and OK never receive
When doing into the code, the UART driver is using same register for TX & RX
Instance->DR
Is that meant, I will have to use flow control, otherwise will not able to handle other device quick response ??
2017-05-02 03:49 PM
It is not a memory cell, the two types of access go to different holding registers within the USART.
If you don't turn echo off (ie ATE0<CR><LF>) I'd expect you see the 'AT<CR><LF>' too.
The HAL is rather a cluster, I've got code here from ST that habitually blocks and loses data, something I'd try to avoid.