Program won't run after upload

[Qwyntex]

I have designed my own PCB and I have the problem that while the code uploads successfully, it doesn't run.

I have checked NRST and BOOT0 and both should not be the problem. I have found a similar issue where the chip didn't get a clock signal and therefor was stuck. I have used the debugger to step through the code and it went past HAL_Init but I never come past SystemClock_Config, when trying to step into it the debugger throws 'Cannot find bounds of current function'. I am new to designing PCBs and I don't really know where to go from here or what the issue could be.

It is not the debugger itself as I can run the blinking sketch with no problems on a dev board that I have bought, which is why I have attached the schematic. I can also provide the PCB layout but I think it is much more likely that I made a basic mistake than that the layout is the culprit.

Thank you

[Tesla DeLorean]

>>IDE keeps crashing

What IDE, you keep mentioning "Sketches" which makes me think Arduino. Do you have some loader between you and the code you're running?

Is it compiling / linking for 0x08000000 operation?

[Qwyntex]

The IDE is the STM32CubeIDE. I guess I just internalized using the word sketches from Arudino and didn't want to write 'code' all the time. I'll just write 'script' or 'code' from now on.

As for the current drawing problem, I didn't know that. I've put the LED there because the dev board I have did, too. I'll change that in the next version but for now, is it actually the problem? Even when the LED should be off and isn't drawing any current the HAL_Delay gets stuck in its loop.

> Is it compiling / linking for 0x08000000 operation?

yes

[Qwyntex]

That I couldn't use the internal clock was because I had still enabled the controller as a USB device which wouldn't allow me to use the internal clock. After I changed that I could manually resolve the clock issues and because it was the dialog box that crashes the IDE I was able to generate the code.
It still doesn't work though, the HAL_Delay gets stuck because the uwTick doesn't increase. Uploading the same code without changes works without a problem on the dev board.

[Qwyntex]

Should I open a new post for this? It might make it easier to find for other people with the same issue and the original question was answered in the first reply by Peter.

[Tesla DeLorean]

You could, I suppose, but already a bunch of detail here, I'd press on..

The SysTick not working is a bit odd. Suggests some issue with NVIC or VTOR configuration, or simply not started. Was a different TIM selected for timing purposes? SysTick is a "System Handler" rather than and interrupt in the broader sense.

Is this example something you could share on GitHub?

Look at HAL_Init() code

F411, no issues are jumping to top-of-mind about odd failings..

[Qwyntex]

Interrupts for the System Tick timer are enabled in the NVIC and I don't think the issue lies in the vector tables either because it runs just fine on the F411 on my dev board (the MCU is exactly the same model, I chose it to not have to modify my code after receiving the PCB). Correct me if I am wrong but the vector tables shouldn't change from one physical chip to another only for different types, right?

There was, at the beginning, a different timer used but after I figured out the clock configuration issue had something to do with just enabling the USB I created a new project from scratch only enabling the HSE and PC13.
Same result. The code runs successfully on the dev board but not on my custom PCB.

That kind of also answers whether I can put it on github. I guess, I could but it really is just a bare bones blinking script.

The only other thing I can currently think of besides another design mistake in my schematic is that there is maybe some firmware or boot configuration flashed to the dev board that isn't on the MCU of my PCB, but I really don't know anything about that.

[Tesla DeLorean]

Well by default SCB->VTOR resets to ZERO, and then what BOOT0 pin maps/shadows there gets to determine what runs, ie FLASH, ROM, RAM,etc

The actual address then usually gets established in SystemInit() with a bunch of defines getting in the way of SCB->VTOR = 0x08000000;

You could perhaps re-gen the project, or use one of the NUCLEO or DISCO examples, watching to address the PLL and HSE_VALUE differences.

When I make a template project for a new board I tend to get a UART working with STDIO so printf() works, and get Error_Handler() and HardFault_Handler() to output actionable output via that channel. Also print out the MCU, AHB, and APB clocks so I know what the machine thinks it's doing.

Check that the Hard Fault works, good way to confirm the Vector Table is in order.

[MM..1]

Try change LED resistor to more as 1k (120R on PC13 is bad) and blue leds is low current

Second set in clock HSE without PLL. All clk 25M ... test when not work  switch to HSI without PLL ...

[Qwyntex]

Not using PLL didn't change anything and using the HSI didn't change anything either, neither with or without PLL.

How likely do you all think it is because of the LED? I didn't design the board with the intention of changing components (which I admit wasn't smart for a prototype) and it wouldn't be trivial nor fast to do.

I would prefer to have some confident that that is the issue first.

But since this seems to be the only difference, I could see it being the problem. Still, what do you think?

[Qwyntex]

I can't find any errors with the debugger and the Hard Fault seems to work. I didn't have time right now to get UART working, I will do that and print out the clocks if you think it's worth it

I just have a few other things to do right now