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

[rozehtiyan]

Posted on January 03, 2016 at 07:39

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:

http://img4.uplood.fr/free/t7ty_csr.png

And I think this panel is showing the situation of the MCU:

http://img4.uplood.fr/free/hqwe_prcc.png

Any idea, suggestion,...? A not completely relevant question: When I was checking my MCU by a simple blink program, I saw an interesting thing in these GPIO registers. I mean IDR and ODR:

http://img4.uplood.fr/free/9lbx_idr.png

And this is ODR and my simple program:

http://img4.uplood.fr/free/r3cc_odr.png

For example look at ODR15 and IDR15 bits. is it normal? or IDR2 and ODR2? #stm32f1 #stm32f103rbt6

[waclawek.jan]

Posted on January 03, 2016 at 12:31

> it doesn't work

Elaborate. What is the expected behaviour and in what way does your observation depart from it? > For example look at ODR15 and IDR15 bits. is it normal? RM0008 9.1.1 General-purpose I/O (GPIO) [...] The JTAG pins are in input PU/PD after reset: PA15: JTDI in PU PA14: JTCK in PD PA13: JTMS in PU PB4: NJTRST in PU > IDR2 and ODR2? What's wrong with those? They are both zero. JW

[Tesla DeLorean]

Posted on January 03, 2016 at 12:59

Try testing it by just using the HSI clock that it starts with rather than using the HSE/PLL. ie don't change any of them, proceed directly to GPIO toggling code, etc.

If that works, then look at the PLL and FLASH settings. You can also examine and verify the internal clocks via the MCO (PA8) pin.

[rozehtiyan]

Posted on January 04, 2016 at 07:54

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.

[rozehtiyan]

Posted on January 04, 2016 at 07:59

Thanks Clive for answer.

Why HSI? I think when HSE faild to make clock, STM32 switch to use HSI automatically. isn't it correct? Why FLASH settings? how can that help me?

[waclawek.jan]

Posted on January 04, 2016 at 11:27

> 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. JW

[Tesla DeLorean]

Posted on January 04, 2016 at 21:16

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.