cancel
Showing results for 
Search instead for 
Did you mean: 

GPIO's On external target not working

timistof
Associate III
Posted on March 28, 2011 at 18:38

Hello everyone.

I'm trying to get the gpio's working on an external target (st32f103zd).

I'm using the Atollic Truestudio lite STM32 discovery ide.

The code i'm using works fine on the ''internal target'', the mcu on the board. Therefore i know that the gpio code is good. Also, I can debug the external mcu with swd and verify that it's working correctly.

On my external target, i've got 14.745 mhz audio crystal as HSE clock. My scope tells my it's running correctly. I can enable / disable this clock from software, although i can't get it to output any clcok synal as external (MCO) clock.It seems like everything interfacing to the outside of the mcu is not working.. I know i should enable ABP2 clocks for the gpio's to work.

Anyone have any ideas? Am I missing obvious some init stuff that doesn't get called on the external target for some reason?

Cheers,

Tim

#external-target #gpio
5 REPLIES 5
Posted on March 28, 2011 at 20:57

We'll assume ''internal'' means simulated.

Without seeing your code or schematics, we'll guess that you're failing to set the clocks or the pin drivers for the GPIO pins, or have not wired up all the power pins on the device.

If you want someone to critique your code, you'll need to post it.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
timistof
Associate III
Posted on March 29, 2011 at 18:30

Well with ''internal'' i mean the mcu on the stm32-discovery.

It logical to assume that i'm not initializing the gpio's correctly, but the same code (the main.c at least) works on the discovery, but doesn't on the external board.

The problems seem to stem from the startup code (system_stm32f10x.c) that get's called before main().

This code sets the sysclock to use the external 8 mhz crystal (HSE) on the discovery board, together with pll

Today i started fiddling with this file a bit and noticed that sometimes the gpio's wouldn't work, but after a hardware reset they would. Seeing the behaviour made me focus my efforts on the stm32 first.

Here's my main.c to be sure. It relies on the Standard Peripherals Library.

http://www.codepaste.net/jeb7uk

http://www.codepaste.net/jeb7uk

I'm thinking that the correct route would be the set the PLLSource to HSI, PLLMUL to 9x, usb prescaler /2. This way SYSCLK would be 48 mhz. Then AHB prescaler to 1, as well as APB2. APB1 prescaler would be 2 for 24 mhz PCLK1

Thus far I haven't seen any change in the gpio behaviour (i can still debug the stm32 ok), but I'll try mucking with the clocks some more.

donald2
Associate II
Posted on March 29, 2011 at 18:53

What changes if you enable the GPIO port clocks before setting the pin directions rather than after?

timistof
Associate III
Posted on March 29, 2011 at 20:11

Yes, that was exactly the kind of simple thing that I hoped someone would point me to. It worked! Thanks a lot!

Andrew Neil
Evangelist
Posted on March 29, 2011 at 23:56

''The code i'm using works fine on the ''internal target'', the mcu on the board. Therefore i know that the gpio code is good.''

Lesson learned that ''working'' code is not necessarily ''correct'' code...?