Hard Fault on UART receive Interrupt in NUCLEOF413ZH!

[aatif shaikh]

Hi All,

I'm working on a project wherein I required multiple UART. So, as suggested on my previous question, I've brought the NUCLEOF413ZH. Unfortunately, this NUCLEO has several issues. Currently, I'm using all the 10 UART, but some of them having "hard fault" on receive Interrupt (there is no issue with my buffer management because code flow is not even entering the IRQ functions) and some of them printing GARBAGE on transmit line. I've checked everything but couldn't find anything wrong with my code!

Still, if anyone could review my code whether is there anything wrong with my initialization part or some predefined macros, library or controller issues.

Moreover, can anyone suggest me a suitable crystal value for this board, which could fit perfectly and I can get 100Mhz system clock.

Board: NUCLEOF413ZH

Library: Standard peripheral libraries (STM32F4xx_DSP_StdPeriph_Lib_V1.8.0).

ID: Keil uV5.0.

[Tesla DeLorean]

I think ST provides a BOM for the parts it would use. Currently you're getting an 8 MHz from the ST-LINK for HSE BYPASS mode on the F4

Max input rate would be 50 MHz, or 25 MHz for a simple crystal

Have your Hard Fault handler output actionable data via a UART or SWO/SWV channel so you can root cause the failure. Check for null or corrupted pointers within structures, peripheral instances, or callbacks. Check adequate stack, see startup.s, Keil defaults really small.

[aatif shaikh]

Thanks @Community member​ ,

The default startup-file in the template code of SPL4XX's is selected to startup_stm32f412xg. Hence, it was generating a "Hard Fault".

About crystal, I've connected an external crystal of 8Mhz, but there is no perfect combination of PLL-M, PLL-N, PLLP, PLL-Q and PLL-R which will gives me exact 50Mhz. Same goes for 100Mhz too. Checked on CubeMX software.

In addition to that, do you know could I change or re-select the startup-file in Keil?

[waclawek.jan]

> some of them having "hard fault" on receive Interrupt

How do you know it's on receive interrupt?

Don't you try to gear up the clocks without adequately change the FLASH latency?

I wouldn't be quite sure the SPL handles 'F413 flawlessly.

JW

[aatif shaikh]

> How do you know it's on receive interrupt?

1. After initialization of UART peripheral, I've connected a TTL device on the UART pins.
2. Via any Hyper/Real Terminal application on a windows PC, I had monitoring the data flow.
3. Resultant: whenever I was sending some data From Termial application, I can see the code is transfering.

I've got the answer: The default startup-file in the template code of SPL4XX's is selected to startup_stm32f412xg. Hence, it was generating a "Hard Fault".