STM32 Cannot read GPIO status

[rob]

Posted on May 11, 2013 at 10:46

I've been trying for a week now, but I can't seem to read the status of the GPIO ports of the STM32F103RB. can turn LED's on, and transmit CAN, but really struggling to see what the issue is with this one. newish to ARM having previously worked with PIC's, so I know its probably my lack of understanding of what going on somewhere. I have Keil UV4, and have used the samples/librarys from ST's website.

I've simplified the code so all it shoudl do is sample GPIOD bit 0, and turn the LED's on/off to show the switch has been pressed. The hardware is a olimexino

https://www.olimex.com/Products/Duino/STM32/OLIMEXINO-STM32/

/* Includes ------------------------------------------------------------------*/
#include ''stm32f10x.h''
#include ''STM32vldiscovery.h''
/** @addtogroup Examples
* @{
*/
/* Private typedef -----------------------------------------------------------*/
/* Private define ------------------------------------------------------------*/
/* Private macro -------------------------------------------------------------*/
/* Private variables ---------------------------------------------------------*/
GPIO_InitTypeDef GPIO_InitStructure;
/* Private function prototypes -----------------------------------------------*/
void Delay(__IO uint32_t nCount);
/* Private functions ---------------------------------------------------------*/
/**
* @brief Main program.
* @param None
* @retval None
*/
int main(void)
{
/*!< At this stage the microcontroller clock setting is already configured, 
this is done through SystemInit() function which is called from startup
file (startup_stm32f10x_xx.s) before to branch to application main.
To reconfigure the default setting of SystemInit() function, refer to
system_stm32f10x.c file
*/ 
/* Configure all unused GPIO port pins in Analog Input mode (floating input
trigger OFF), this will reduce the power consumption and increase the device
immunity against EMI/EMC *************************************************/
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOB |
RCC_APB2Periph_GPIOC | RCC_APB2Periph_GPIOD |
RCC_APB2Periph_GPIOE, ENABLE);
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_All;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AIN;
GPIO_Init(GPIOA, &GPIO_InitStructure);
GPIO_Init(GPIOB, &GPIO_InitStructure);
GPIO_Init(GPIOC, &GPIO_InitStructure);
GPIO_Init(GPIOD, &GPIO_InitStructure);
GPIO_Init(GPIOE, &GPIO_InitStructure);
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOB |
RCC_APB2Periph_GPIOC | RCC_APB2Periph_GPIOD |
RCC_APB2Periph_GPIOE, DISABLE); 
/* Initialize Leds LD3 and LD4 mounted on STM32VLDISCOVERY board */
STM32vldiscovery_LEDInit(LED3);
STM32vldiscovery_LEDInit(LED4);
/* Initialise USER Button */
STM32vldiscovery_PBInit(BUTTON_USER, BUTTON_MODE_GPIO); 
while (1)
{
/* Turn on LD2 and LD3 */
STM32vldiscovery_LEDOn(LED3);
STM32vldiscovery_LEDOn(LED4); 
/* Insert delay */
Delay(0xAFFFF);
/* Turn off LD3 and LD4 */
STM32vldiscovery_LEDOff(LED3);
STM32vldiscovery_LEDOff(LED4);
if(0 == STM32vldiscovery_PBGetState(BUTTON_USER))
{
/* Turn off LD3 and LD4 */
STM32vldiscovery_LEDOff(LED3);
STM32vldiscovery_LEDOff(LED4);
/* Insert delay */
Delay(0xFFFFF);
/* Insert delay */
Delay(0xFFFFF);
}
/* Insert delay */
Delay(0xAFFFF);
}
}

and configured here:

/** 
* @brief STM32F100 Button Defines Legacy 
*/ 
#define Button_USER BUTTON_USER
#define Mode_GPIO BUTTON_MODE_GPIO
#define Mode_EXTI BUTTON_MODE_EXTI
#define Button_Mode_TypeDef ButtonMode_TypeDef
/** @addtogroup STM32vldiscovery_LOW_LEVEL_LED
* @{
*/
#define LEDn 2
#define LED3_PIN GPIO_Pin_1 
#define LED3_GPIO_PORT GPIOA
#define LED3_GPIO_CLK RCC_APB2Periph_GPIOA 
#define LED4_PIN GPIO_Pin_5 
#define LED4_GPIO_PORT GPIOA
#define LED4_GPIO_CLK RCC_APB2Periph_GPIOA 
/**
* @}
*/ 
/** @addtogroup STM32vldiscovery_LOW_LEVEL_BUTTON
* @{
*/ 
#define BUTTONn 1
/* * @brief USER push-button
*/
#define USER_BUTTON_PIN GPIO_Pin_0
#define USER_BUTTON_GPIO_PORT GPIOD
#define USER_BUTTON_GPIO_CLK RCC_APB2Periph_GPIOD
#define USER_BUTTON_EXTI_PORT_SOURCE GPIO_PortSourceGPIOD
#define USER_BUTTON_EXTI_PIN_SOURCE GPIO_PinSource0
#define USER_BUTTON_EXTI_LINE EXTI_Line0
#define USER_BUTTON_EXTI_IRQn EXTI0_IRQn
/**
* @}
*/ 
/** @defgroup STM32vldiscovery_LOW_LEVEL__Exported_Functions
* @{
*/ 
void STM32vldiscovery_LEDInit(Led_TypeDef Led);
void STM32vldiscovery_LEDOn(Led_TypeDef Led);
void STM32vldiscovery_LEDOff(Led_TypeDef Led);
void STM32vldiscovery_LEDToggle(Led_TypeDef Led);
void STM32vldiscovery_PBInit(Button_TypeDef Button, ButtonMode_TypeDef Button_Mode);
uint32_t STM32vldiscovery_PBGetState(Button_TypeDef Button);

#rtfm

[rob]

Posted on May 11, 2013 at 11:45

Fixed it - just realized that D0 labelled on the olimexino board isn't actually PortD bit 0, but PortA bit3!!  I will never ever get that time back.

[Andrew Neil]

Posted on May 11, 2013 at 22:56

''I will never ever get that time back.''

But, hopefully, you will learn the important lesson to

always

check the schematics!

From the Keil cross-post

http://www.keil.com/forum/23062/

The fact that it's also labelled ''RXD2'' should have been a clue...

This ''Olimexino'' is an Arduino lookalike:

https://www.olimex.com/Products/Duino/STM32/OLIMEXINO-STM32/

So I guess the ''shield'' pin naming follows the Arduino - which has nothing whatsoever to do with STM32.

(I'm not sure that it even had anything to do with the original AVR pin names?)

But the User Manual does include a full schematic - which does show which shield pins connect to which STM32 pins:

https://www.olimex.com/Products/Duino/STM32/OLIMEXINO-STM32/resources/OLIMEXINO-STM32.pdf