STM32F103RET6 bare metal SPI3

[joesnyder]

I have SPI1 working in bare metal on a 48 pin version of the same chip, but I am having difficulty with SPI3 migrating to a 64 pin.  For reference, I have attached the most recent stm32f103x6.h file from the Cube MX F1 package (STM32Cube_FW_F1_V1.8.0).  

SPI3 is on APB1, and SPI1 is on APB2.

The first strange thing, if you look at line 17 of the code below, there is no "RCC_APB1ENR_SPI3EN" defined in the stm32f103x6.h file.  When using SPI1, you can use "RCC_APB2ENR_SPI1EN" - which IS defined in the .h file.  So I didn't think much of it and just manually set bit 15 of APB1ENR, corresponding to the SPI3 enable (Page 116 of reference manual RM0008).

The second strange thing is "SPI3" simply is not defined in the stm32f103x6.h file.  For instance, if you change line 34 to "SPI3->CR1...", it won't recognize SPI3 and gives an error.

It's acting like SPI3 doesn't exist on this chip.  There are no references to SPI3 (or SPI2 for that matter) in the stm32f103x6.h file.  Table 2 on page 11 of the datasheet says STM32F103Rx has 3 SPIs.  When you go to build it in CubeMX, it shows SPI3 as being available. When you export the CubeMX project and build it, there are no errors with it referencing SPI3...so SPI3 has to be on this chip.

Does anyone know how I reference an instance of SPI3 in bare metal?  And why SPI2&3 are completely missing from the stm32f103x6.h file?  Or is there some strangeness where you just refer to it as "SPI1", and by the alternate function mapping of the pins, it will still work somehow?    

void init_spi3(void)
{

	// Note on ref manual page 699: need to disable JTAG because SPI3 conflicts with JTAG pins
	// Enable the clock for AFIO
	RCC->APB2ENR |= RCC_APB2ENR_AFIOEN; //
	// Disable JTAG pins (set SWJ_CFG[2:0] to 100)
	AFIO->MAPR |= AFIO_MAPR_SWJ_CFG_JTAGDISABLE; //

	//SPI3, want master transmit-only:
	//PA15 NSS
	//PB3 SCK
	//PB5 MOSI

    RCC->APB2ENR    |= RCC_APB2ENR_IOPAEN;  // enable GPIOA clock
    RCC->APB2ENR    |= RCC_APB2ENR_IOPBEN;  // enable GPIOB clock
    RCC->APB1ENR    |= (1<<15);				// RCC_APB1ENR_SPI3EN is never defined in stm32f103x6.h...just manually set bit 15 to enable SPI3 clock (Page 116 of ref manual)

    //Per table 25 on page 167 of reference manual, for SPIx:
    //PA15 SPI3 NSS -> Want alternate function push-pull
    //PB3 SPI3 SCK -> Want alternate function push-pull
    //PB5 SPI3 MOSI -> Want alternate function push-pull

    // init PA15 NSS  - Mode = 01 (10Mhz output), CNF = 10 = alternate function push-pull...ref manual pg 171
    GPIOA->CRH |= (GPIO_CRH_MODE15_0 | GPIO_CRH_CNF15_1);

    // init PB3 SCK  - Mode = 01 (10Mhz output), CNF = 10 = alternate function push-pull...ref manual pg 171
    GPIOB->CRL |= (GPIO_CRL_MODE3_0 | GPIO_CRL_CNF3_1);

    // init PB5 MOSI  - Mode = 01 (10Mhz output), CNF = 10 = alternate function push-pull...ref manual pg 171
    GPIOB->CRL |= (GPIO_CRL_MODE5_0 | GPIO_CRL_CNF5_1);

    // initialize the SPI configuration register (sequence page 707, SPI_CR1 register on page 742)
    SPI1->CR1  =  SPI_CR1_DFF   // 16-bit data frame !!!!!!!!!!!!!!DOES NOT RECOGNIZE SPI3 HERE!!!!!!!!!!!!
                | SPI_CR1_SSM   // software slave management enabled
                | SPI_CR1_SSI   // internal slave select
                | SPI_CR1_MSTR  // SPI master mode
                | SPI_CR1_BR_2; // bit rate prescale /32 (72MHz/32 = 2.25MHz)

    SPI1->CR1  |= SPI_CR1_SPE;  // enable SPI  !!!!!!!!!!!!!!DOES NOT RECOGNIZE SPI3 HERE!!!!!!!!!!!!
}

[Peter BENSCH · Accepted solution]

Well, there are four subfamilies of the STM32F103. Your variant belongs to the so-called High Density family, whose second letter after the STM32F103 is either C, D or E (denotes the Flash size). However, you have been confused by the last digit 6, which indicates the temperature range, and have inadvertently used the header file of the Low Density family. You must therefore use the header file stm32f103xe.h.

Hope that helps?

Regards
/Peter

[joesnyder]

Oh wow, you are correct, that is very confusing.  I thought about it all night and knew it must be the wrong file somehow, yet I was positive STM32F103RET6 corresponded to stm32f103x6.h.  But this chip has been around for ages, so how could it have gone this long with SPI2 and SPI3 being left out of the header file.... 

Thank you for the clarification Peter!