2020-09-18 01:23 PM
I am just trying to use the STM32CubeMX tool.
The application needs two USARTs. One for communication with external processor. This will be an RS485 interface. The PCB will have hardware for RS485 transceiver, mux/demux for directionality of transmission. Due to this, I am configuring this USART in asynchronous mode (no flow control for RS232 or RS485). This USART1 will also be used as a bootloader. Please confirm if this configuration will work. For the NVIC settings, I enabled the USART1 global interrupt. Will this interrupt trigger both on transmit and receive bytes?
I also need the serial wire debug capability. I want to configure a separate USART (USART2)for this. Do I configure this the same way as USART1? Initially I will be using the ST-Link debugging tool, later maybe the JLink SWD. I will disable the interrupt for this. Please confirm if correct.
Thanks,
Priya
Solved! Go to Solution.
2020-09-18 02:37 PM
Not looking to wade into your due diligence work, or CubeMX issues.
The UARTs each have their own IRQ that the NVIC manages, at a peripheral level the interrupt can have multiple sources, you can individually enable RX and TX interrupts, and the service code checks and dispatches based on those which are flagging.
USART1 and USART2 are materially similar, they may reside on different APB buses, which may have different clocks. The HAL usually does the math for you to get to specific baud rates.
SWDIO, SWCLK and NRST connectivity to the debugger are suggested.
The ROM based boot loader is not tolerant to noise on multiple UART RX at reset, like a GPS receiver, or other signalling that might be mistaken for an active connection.
2020-09-18 02:37 PM
Not looking to wade into your due diligence work, or CubeMX issues.
The UARTs each have their own IRQ that the NVIC manages, at a peripheral level the interrupt can have multiple sources, you can individually enable RX and TX interrupts, and the service code checks and dispatches based on those which are flagging.
USART1 and USART2 are materially similar, they may reside on different APB buses, which may have different clocks. The HAL usually does the math for you to get to specific baud rates.
SWDIO, SWCLK and NRST connectivity to the debugger are suggested.
The ROM based boot loader is not tolerant to noise on multiple UART RX at reset, like a GPS receiver, or other signalling that might be mistaken for an active connection.
2020-09-18 02:40 PM
> Will this interrupt trigger both on transmit and receive bytes?
If you enable those interrupt in CR1, yes.
> I also need the serial wire debug capability. I want to configure a separate USART (USART2)for this. Do I configure this the same way as USART1?
SWD doesn't use UART. It uses the SWDIO/SWCLK pins. There is a VCP capability of newer (ST-Link/V3) debuggers, in which case you configure that just like you would any UART, but it's separate from the SWD function.
2020-09-21 06:37 AM
thank you for your replies. I have attached a picture of a possible bootloader connection. Is this likely to also be noise prone?
If it will be, I will post again with a follow up question.
I am waiting for the dev board to come. STMCubeMX has a global USART1 wake up interrupt through EXT1 line 25, same
as the reference manual. Will this interrupt trigger for every receive and transmit byte?
Thanks,
Priya
2020-09-21 07:02 AM
If it's repeatable, it's probably not noise. RS485 is quite tolerant of noise since it's a differential signal, as long as it's wired correctly. You should have external pullups on the UART lines. Length of wires will also matter, which can't be determined from a schematic.
Regardless, I don't think noise would even explain the results you're seeing. A software bug does.
2020-09-21 07:05 AM
Thank you. UART to RS-485 HW on the PCB will all be layout connections, no cables. RS485 Cable comes in only to connect to the external processor.
2020-09-21 07:11 AM
I confused this post with another one. Ignore most of my last post, except that RS485 is very tolerant of noise.