STM32L151 MISO AF config issue

Alex Yang · ‎2015-02-26

Posted on February 26, 2015 at 18:39

Hi all, I'm using L1 series for the very first time.

The code is generated with CubeMX 4.6.0 and built with MDK 5.12.0. I've had Cube MX copy the device library into the project directory.

My board carries an STM32L151C8T6, SPI2 has been configured with following code:

/* SPI2 init function */

void MX_SPI2_Init(void)

{

hspi2.Instance = SPI2;

hspi2.Init.Mode = SPI_MODE_MASTER;

hspi2.Init.Direction = SPI_DIRECTION_2LINES;

hspi2.Init.DataSize = SPI_DATASIZE_8BIT;

hspi2.Init.CLKPolarity = SPI_POLARITY_HIGH;

hspi2.Init.CLKPhase = SPI_PHASE_2EDGE;

hspi2.Init.NSS = SPI_NSS_SOFT;

hspi2.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_128;

hspi2.Init.FirstBit = SPI_FIRSTBIT_MSB;

hspi2.Init.TIMode = SPI_TIMODE_DISABLED;

hspi2.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLED;

HAL_SPI_Init(&hspi2);

}

An ADXL345 has been connected to SPI2 and when address 0 is read, it returns device ID 0xE5. When I monitor MISO with my oscilloscope, it shows exactly the same value. MOSI also checks out, the address byte was sent correct.

But my code keeps reading 0x00, I checked every step within the library source code and confirmed that DR didn't contain the correct value when being read.

So I tweaked registers to find a combination which might offer some clue. I noticed that PB14(MISO) has been put into floating input mode, while SCLK and MOSI are in AFPP mode.

Could't quite recall how exactly I set up MISO with F1 and F2 series. But since AFPP supposedly is only meant for outputs, I guess it makes sense.

Then I traced the code which initializes SPI2 pins

Version info says:

* File Name : stm32l1xx_hal_msp.c

* Date : 17/02/2015 00:41:04

* Description : This file provides code for the MSP Initialization

* and de-Initialization codes.

Starting at Line 297:

/**SPI2 GPIO Configuration

PB13 ------> SPI2_SCK

PB14 ------> SPI2_MISO

PB15 ------> SPI2_MOSI

*/

GPIO_InitStruct.Pin = GPIO_PIN_13|GPIO_PIN_15;

GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;

GPIO_InitStruct.Pull = GPIO_NOPULL;

GPIO_InitStruct.Speed = GPIO_SPEED_VERY_LOW;

GPIO_InitStruct.Alternate = GPIO_AF5_SPI2;

HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

GPIO_InitStruct.Pin = GPIO_PIN_14;

GPIO_InitStruct.Mode = GPIO_MODE_INPUT;

GPIO_InitStruct.Pull = GPIO_NOPULL;

HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

Guess I'm not supposed to modify that.

Then at some point I changed that floating input mode into AFPP mode and all of a sudden I could read the correct value.

So, does the library hold a bug or is it more to PB14 than just changing its mode? Thank you for your time.

#stm32l1-spi

raptorhal2 · ‎2015-02-26

Posted on February 26, 2015 at 22:13

So SPI can accomodate master/slave differences, this is in my copy of the GPIO initialization in the MX hal_msp initialization file:

GPIO_InitStruct.Alternate = SPIx_MISO_AF;

Not sure why your initialization is different. Are you running another initialization after hal_msp is done ?

Cheers, Hal

Alex Yang · ‎2015-02-26

Posted on February 27, 2015 at 08:01

Nope, I'm not touching either SPI2 or related GPIO initialization after hal_msp initialization.

Later I noticed that hal_msp is placed in the src folder, instead of the driver folder, so it's not part of the library, I guess it's project dependent after all?

SPIx_MISO_AF is nowhere to be found in my project, where is it defined in your library？ We're definitely using different libraries. As mentioned above, my code uses GPIO_AF5_SPI2, which is definef from stm32l1xx_hal_gpio_ex.h.

#define GPIO_AF5_SPI2 ((uint8_t)0x05) /* SPI2/I2S2 Alternate Function mapping */

I've also left out the part that AF register for PB14 also needs to be set to AF5, just like PB13 and PB15.

Things are normal after I changed my hal_msp code:

GPIO_InitStruct.Pin = GPIO_PIN_13 | GPIO_PIN_14 | GPIO_PIN_15;

GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;

GPIO_InitStruct.Pull = GPIO_NOPULL;

GPIO_InitStruct.Speed = GPIO_SPEED_VERY_LOW;

GPIO_InitStruct.Alternate = GPIO_AF5_SPI2;

HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

stm32cube-t · ‎2015-03-18

Posted on March 18, 2015 at 11:05

Hello this will be corrected in next STM32CubeMX 4.7 release.