My MCU doesn't work although I have control on it over debug

Hi fellas
I have soldered my MCU (it's STM32F103RBT) on the board and I also can program/erase it. I even have control on it over debug(SWD) then I think everything is okay but it doesn't work. this is RCC's registers:

Thanks waclawek.jan for reply
I have downloaded two programs on the MCU. the first one was my main program and when it didn't work on the MCU then I tried to check the MCU by a blink program and it didn't work again. for example I tried to toggle PA3 to high or low state (in the blink program) but when I observed PA3, nothing happened.

>What's wrong with those? They are both zero.

Yes but shouldn't they either be in high or low state? I mean each GPIO should either be input or output. IDR show us input and ODR output. but when you look at ODR15 and IDR15 you saw both bits are in high state. what does that mean? we have input and output!!? and also I'm using SWD then just PA13 and PA14 are busy.

> I tried to toggle PA3 to high or low state (in the blink program) but when I observed PA3, nothing happened.

Break/stop the processor and toggle the respective pin in ODR manually,
from the debugger. Measuring directly on the pin, does its output
voltage change?

> I mean each GPIO should either be input or output. IDR show us input
and ODR output. but when you look at ODR15 and IDR15 you saw both bits
are in high state. what does that mean?

You misunderstand the purpose of IDR and ODR. ODR is a holding register,
and the value of its bits is output to a pin *if* that pin is set to
GPIO Out mode. IDR always reflects the current voltage level of the
pins. Please review carefully the GPIO chapter in RM.

> Why HSI? I think when HSE faild to make clock, STM32 switch to use HSI automatically. isn't it correct?

Clive's point is that there's less chance for various errors when you
simply leave RCC untouched in its reset state. Start from that, and in
case of success proceed to HSE and PLL.

> Why FLASH settings? how can that help me?

FLASH waitstates should reflect the system clock frequency and the
supply voltage. Consult the RM and datasheet. Again, leaving RCC in its
reset state (i.e. main clock is directly from HSI) avoids the need to
set that.

Why HSI? I think when HSE failed to make clock, STM32 switch to use HSI automatically. isn't it correct?

Because the processor starts executing with the HSI clock, and can continue to do that.

The STM32 does what your code tells it to do. If your code senses that HSE doesn't start it might sit in an endless loop waiting. I don't know exactly what you are doing. Try turning off "run to main()" and step through the code.

If you run at 72 MHz without setting additional wait states for the Flash, then the processor will likely crash.

IDR should reflect the state of the pins regardless of what mode you are in, contrast the levels reported by the IDR against the state of the pins as measured externally.

I have suggested just using the HSI clock so you can eliminate the clock/pll/flash settings from the list of reasons why your code isn't functioning as expected. It's a technique called bisection, where you divide things into pieces and see which piece does or does not work, allowing you to focus down on what is broken, and eliminating things that do work from your search.

It would be easier to understand what you are doing if you present all the code, rather than selective screen grabs.