4 years, 9 months ago.

Problem with the SPI clock on D13


I'm working on an STM32F7 Disco and I need to use the NFC Shield v2.1. I've already made it work on an Arduino Uno, and i managed to recover the NFC Tag of NFC badge.

I now need to use this shield in the same way with my STM32F7 Discovery board. I managed to initialize the SPI2 (D11, D12, D13 Pins) but the NFC Shield ins't reconized.

I think it's because of the SPI Clock, which amplitude is way too low, compared to Arduino Uno's SPI Clock. (like 2,5V for the STM32, and 5V for the Arduino).

I don't know if it's because of the way i initialized it, or because the SPI librairie of Mbed ins't appropriate with an STM32F7 board.

Here is my code :

SPI spi(D11, D12, D13); // mosi, miso, sclk

DigitalOut cs(D10);

PN532_SPI pn532spi(spi, D10);
PN532 nfc(pn532spi);

uint32_t    ErrorCounter = 0;

/* Private function prototypes -----------------------------------------------*/
void SystemClock_Config(void);
void Error_Handler(void);
//static void MX_GPIO_Init(void);
//static void MX_SPI2_Init(void);

int main(void)


 // MX_GPIO_Init();
 // MX_SPI2_Init();

    cs = 0;


    lcd.DisplayStringAt(0, 100, (uint8_t *)"TEST SPI", CENTER_MODE);
    nfc.begin(); // begin NFC communication


    uint32_t versiondata = nfc.getFirmwareVersion();
    if (! versiondata)
        lcd.DisplayStringAt(0, 20, (uint8_t *)"MODULE NON DETECTE 2", CENTER_MODE);
        while (1); 
    lcd.DisplayStringAt(0, 100, (uint8_t *)"TEST NFC BEGIN", CENTER_MODE);


    while (1)

void SystemClock_Config(void)
  HAL_StatusTypeDef ret = HAL_OK;
  RCC_ClkInitTypeDef RCC_ClkInitStruct;
  RCC_OscInitTypeDef RCC_OscInitStruct;
  /* Enable Power Control clock */

  /* The voltage scaling allows optimizing the power consumption when the device is
     clocked below the maximum system frequency, to update the voltage scaling value 
     regarding system frequency refer to product datasheet.  */

  /* Enable HSE Oscillator and activate PLL with HSE as source */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLM = 25;
  RCC_OscInitStruct.PLL.PLLN = 400;
  RCC_OscInitStruct.PLL.PLLQ = 8;
  ret = HAL_RCC_OscConfig(&RCC_OscInitStruct);
  ASSERT(ret != HAL_OK);

  /* activate the OverDrive to reach the 180 Mhz Frequency */
  ret = HAL_PWREx_ActivateOverDrive();
  ASSERT(ret != HAL_OK);

  /* Select PLL as system clock source and configure the HCLK, PCLK1 and PCLK2
     clocks dividers */
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;

  ret = HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5);
  ASSERT(ret != HAL_OK);

Here is the Arduino SPI Clock /media/uploads/EricJ/arduino_spi_clock.jpg

and here is the STM32F7 SPI Clock /media/uploads/EricJ/stm32_spi_clock.jpg

The volt/div is the same for the 2 pictures. Thank you for your help.

Question relating to:

The STM32F746G-DISCO discovery board (32F746GDISCOVERY) is a complete demonstration and development platform for STMicroelectronics ARM® Cortex®-M7 core-based STM32F746NGH6 microcontroller.

4 Answers

4 years, 9 months ago.

Hi Eric. A general suggestion - forget about the NFC board for now. Instead, use the mbed libraries / examples to communicate with the onboard SPI flash memory device. Confirm that you are able to at least read from this SPI memory device. Even though the flash memory is QSPI (quad SPI) - the same flash memory should be fine to operate in the standard and slower SPI mode. This will confirm that the mbed library for SPI is operation if you can read out say the flash memory IDs and compare the ID values against the datasheet for the same flash device. After this is confirmed, then proceed to work with your NFC board. Confirm the pinouts start and land on your shield board correctly. The voltage swing is fine for 3v3 operating processors. You can also validate each of the SPI port pins by simply toggling like a LED blinky at slow speed and confirm that the respective port pin does indeed swing to 3v3 or 0.

4 years, 9 months ago.

Typical Arduino is a 5V device, that is why you see the 5V swing. The STM32F7 and other ARM processors are 3V3 devices. Did you confirm that your NFC shields works at 3V3 powersupply and/or 3V3 controlsignals. Most devices will work at 5V power and with a 3V3 signallevel.

Well, the NFC Shield work with a 5V power supply. For the SPI Clock, I don't have any information.

I just know that the shield is recognized by my Arduino Uno, but not with my STM32F7.

I just edited my post to show you the difference between the 2 clocks. I don't know if the STM32F7 SPI Clock is normal, or is like this because I made a mistake in my initialization.

posted by Eric Jensen 12 Jan 2017
4 years, 9 months ago.


one comment on SW side, you shouldn't have the below calls in your main() : HAL_Init(); SystemClock_Config(); Those functions are called withiin MBED layers and calling them in main may have unknown side effects - can you try to remove them ?

on HW side, you indeed need to check in your NFC shield documentation that it supports 3.3V IOs.

Thank you for your advices. I'll try to remove these functions when i'm home. About the NFC Shield v2.1, I didn't find any informations about its level acceptance for the SPI voltage. I can only test it with my Arduino Uno, which deliver 5V for the SPI controlsignals.

posted by Eric Jensen 13 Jan 2017

I edited by code by only letting the mbed initialisation but the SPI Clock signal stayed the same.

posted by Eric Jensen 14 Jan 2017
4 years, 9 months ago.

Hello, I have another suggestion : The green led LED1 is on the D13 pin (see the pinout image here : https://developer.mbed.org/media/uploads/adustm/xdisco_f746ng_mbed_pinout_v5.png.pagespeed.ic.GbEqVuOXIQ.webp)

You should desactivate it (by unsoldering SB8 in front of D13 pin of connector CN7), I think it damages your SPI_CLOCK signal.

Let us know !

Kind regards


i unsolved the SB8 from the D13 pin, but the SPI clock signal stayed the same.

posted by Eric Jensen 14 Jan 2017