Not getting USART1 interrupt

[StephenG]

Hi,

I'm having a problem trying to get the USART working through the serial driver on an STM32F405. It does work on some old firmware I had on the chip (CMSIS stuff, not ChibiOS).

In ChibiOS, I can send data to the computer, but the micro isn't able to receive. When I put a breakpoint in the ISR, it never gets hit.

I've checked the pin configuration 20 times, pretty sure it's all good. It doesn't seem to be a hardware problem since it worked before. What can I do to further debug?

This is using latest stable ChibiOS.

[Giovanni]

Are the USART pins correctly configured in board.h? I assume you are using a newly created board files set, so the problem is likely there.

Giovanni

[StephenG]

It's possible that something is wrong with the board files because I copied it from the discovery version (which is a STM32F407 which I think our new hardware will also be). But I've checked over it a bunch of times (Both are alternate, push-pull, floating (they have external pull-ups), and AFR is set to the correct number).

I'll post it tomorrow when I get to work.

It's half duplex RS485, so I'll have to have a poke around with a logic analyser to make sure the transmit enable and read enable signals are working correctly, but they are doing the same as the old firmware so it should be fine...

[StephenG]

So I have

Code: Select all

#define GPIOA_USART1_TX             9
#define GPIOA_USART1_RX             10

and in #define VAL_GPIOA_MODER I have set

Code: Select all

PIN_MODE_ALTERNATE(GPIOA_USART1_TX) |  \
PIN_MODE_ALTERNATE(GPIOA_USART1_RX) |  \

VAL_GPIOA_OTYPER has

Code: Select all

PIN_OTYPE_PUSHPULL(GPIOA_USART1_TX) |  \
PIN_OTYPE_PUSHPULL(GPIOA_USART1_RX) |  \

VAL_GPIOA_OSPEEDR has

Code: Select all

PIN_OSPEED_25M(GPIOA_USART1_TX) |      \
PIN_OSPEED_25M(GPIOA_USART1_RX) |      \

(I tried 50M and 100M and it was the same),

VAL_GPIOA_PUPDR has

Code: Select all

PIN_PUPDR_FLOATING(GPIOA_USART1_TX) |  \
PIN_PUPDR_FLOATING(GPIOA_USART1_RX) |  \

(they have external pull-ups)

VAL_GPIOA_ODR has

Code: Select all

PIN_ODR_HIGH(GPIOA_USART1_TX) |        \
PIN_ODR_HIGH(GPIOA_USART1_RX) |        \

and VAL_GPIOA_AFRH has

Code: Select all

PIN_AFIO_AF(GPIOA_USART1_TX, 7) |      \
PIN_AFIO_AF(GPIOA_USART1_RX, 7) |      \

Pretty sure they're all good, and the transmit works fine. I read that for some chips the RX is meant to be an input, but trying that didn't work either...

[StephenG]

Well, I ended up working it out.

Turns out that the hardware designer also connected the RX to UART5, which was set as an output. Setting that to input makes everything work as expected (now I'm really annoyed that I missed that and wasted a lot of time debugging!)

[Giovanni]

This is a common issue, there are limits to the abstractions you can create, at the end it is always matter of HW and manuals.

Giovanni