Problem configuring higher clock speeds for custom board using STM32F446RE with blinky code.

[Murph]

So i have been stuck on this problem for a while and I desperately need some help understanding what could be wrong. I am using STM32CubeIDE v1.8.0 and a NUCLEO STM32F446RE board to test some basic code that blinks an LED. This works absolutely fine. 

I have since built a custom breakout board for the STM32F446RE chip. For some reason, the exact same code that works just fine on the NUCLEO does not work when i configure higher clock speeds in Cube for the custom board. At around 80 MHz (the max being 180 MHz) the code seems to hard fault at random places in the code, and is different each attempt at debugging making it near impossible to figure out what the problem is. But lower speeds seem to run just fine. This makes me believe that my hardware must be lacking somehow. I have followed the datasheet as best as I could for recommended capacitors, voltages on pins, etc. See below for software and hardware details.

Software details: I am programming the custom board using SWD via the ST-Link v2. I have updated the firmware of the ST-Link v2 to the latest available. I have created a new project in Cube, configured PB14 as GPIO out for the LED, configured the pins for SWD, configured the clock, and added the following four lines of code to the main loop. 

HAL_GPIO_WritePin(GPIOB, GPIO_PIN_14, 1);

HAL_Delay(1000);

HAL_GPIO_WritePin(GPIOB, GPIO_PIN_14, 0);

HAL_Delay(1000); 

Hardware details: I am using the 3.3V and GND pins from the St-Link v2 for the power for the custom board. I have attached all VSS and VSSA pins to ground. I have attached all VDD and VBAT pins to 3.3V. I ran a 3.3V line to a ferrite bead, which then leads to VDDA. I added a 100 nF and 10 nF to ground for VDDA. I pulled BOOT0 low. I attached NRST to the RST from the St-Link v2 pin. I use a 4.7 uF capacitor for VCAP to ground. I added 2 x 100 nF decoupling capacitors from the 3.3V line to ground for each VDD pin on the chip (a total of 8 caps) and a 10uF capacitor.

I'm so confused why it works no problem on the Nucleo and not my custom breakout board. Any help would be greatly appreciated. Thanks! 

[TDK]

Sounds like incorrect wait states, or other invalid clock configuration.

[Murph]

Cube's auto generated code uses FLASH_LATENCY_5 in the SystemClock_Config function when i configure for max clock (180 MHz). Going by the datasheet which says that for 180 MHz, use 5 wait states and over-drive ON. I attached a screenshot of the clock config, in case you notice any problems with it.

[waclawek.jan]

> I am using the 3.3V and GND pins from the St-Link v2 for the power for the custom board.

Is it capable to supply sufficient current?

Description otherwise sounds OK, post layout for us to discuss. Also check the connections for potential bad solder joints.

JW

[TDK]

Not real sure. What is the pedigree of the hardware? Reflow at an PCB assembly company or soldered in an at-home lab with substandard tools? Could be soldering problems. I don't see any issues with the clock setup.

What does an analysis of the hard fault codes show?

Edit: JW's idea of a limited current supply seems the most likely. Monitoring the rail with a scope would verify.

[Murph]

The breakout board was produced by JLCPCB. I went through each of the pins and did continuity tests to see if adjacent pins were shorted, but each were fine.

So the hard fault changes depending on if i increase or decrease the clock. At 50 MHz and lower, it works no problem. From 50 MHz to 80 MHz it runs for a little bit before hard faulting somewhere usually after the HAL_Delay was called. Above 80 MHz sometimes it faults in the HAL_RCC_ClockConfig function.

[Murph]

I assume current wouldn't be a problem, since ultimately all the current is coming from a USB port on my laptop, just like with the Nucleo board which has no problems at all. I did continuity tests from the pins of the STM32 to my header pins which were fine, as well as continuity tests between adjacent pins to see if there was any shorting, but it was fine.

I attached a schematic I made of my setup on my breadboard.

[Murph]

I unfortunately don't have a scope to verify. Is there a reason why the Nucleo wouldn't suffer from this but the custom board would? Maybe something inside the ST Link v2 that limits the current? I even tried using the 3.3v and GND pins from the Nucleo board instead, but still no luck.

[TDK]

You're using the onboard ST-Link on the nucleo board? It needs to power both chips in that case.

Edit: although voltage dropping should trigger BOR, not hard faults.

[Murph]

I'm using a separate ST-Link, see attached. I actually have tried to use the onboard ST Link from the nucleo, but that has made no difference.