NUCLEO-F429ZI SPI SCLK unexpected signal

[mbartling]

Description

• Type: Bug
• Priority: Minor

---

Bug

Target
NUCLEO-F429ZI

Toolchain:
GCC_ARM

Toolchain version:
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 6.2.1 20161205 (release) [ARM/embedded-6-branch revision 243739]

mbed-cli version:
1.0.0

mbed os version
MBED_LIBRARY_VERSION 127
MBED 2

Expected behavior
Tested on NUCLEO-F401RE

Actual behavior

Steps to reproduce

1. Attach X-Nucleo-IDB05A1 BLE shield to target (note issue occurs without shield as well)
2. Modify BLE_GAP_Example here such that it uses X_NUCLEO_IDB0XA1 and set IDB0XA1_PIN_SPI_SCK to D13 in X_NUCLEO_IDB0XA1/x_nucleo_idb0xa1_targets.h

[bridadan]

cc @bcostm @adustm

[BlackstoneEngineering]

@screamerbg

[LMESTM]

@mbartling
Just to make sure I understand it right.

Have you modified resistors of your X-nucleo board as described in the below page ?
https://developer.mbed.org/teams/ST/code/X_NUCLEO_IDB0XA1/
This is needed because the SPI_CLK signal is not available on D3 for NUCLEO_F429ZI (whereas this is available on NUCLEO_F401RE)

Also have you made sure that your program doesn't use LED1 ? (as LED1 is defined as D13 and it would conflict with SPI usage) ? Otherwise that could be a reason for unwanted signal behavior.

[mbartling]

I am confused by the wording of the modified resistor page, am I supposed to perform the hardware hack if I am using pin D13?

Also, please note that this is an issue with the F429ZI board itself as I cannot get any of the SPI1_SCLKs to initialize using the mbed API.

[LMESTM]

I haven't tried it myself, but here is my understanding.

From https://developer.mbed.org/teams/ST/code/X_NUCLEO_IDB0XA1/: The X-NUCLEO-IDB04A1 and X-NUCLEO-IDB05A boards are using D3 pins by default. Those boards need to be HW modified (resistors change) to use D13 instead of D3.

For NUCLEO_F401RE, the resistor change is not required, because SPI1 pin SPI_SCLK can be routed to D3 as shown here: https://developer.mbed.org/platforms/ST-Nucleo-F401RE/

But in case of NUCLEO_F429ZI, it is mandatory to make this change, because D3 pin does not offer possibility to mux SPI_SCLK to D3. You can see muxing options here: https://developer.mbed.org/platforms/ST-Nucleo-F429ZI/

So in order to have the example working ok with NUCLEO_F429ZI, I think that you need to:

1. modify the HW resistors
2. define the IDB0XA1_D13_PATCH compilation switch (this is better than modifying the code because maybe IDB0XA1_D13_PATCH is used somewhere else as well)
3. make sure not to use LED1 in your program because it would conflict with SPI_SCLK on D13

One more question: when you did the SPI trace "Expected behavior Tested on NUCLEO-F401RE". Where have you put the probes ?

hope this helps ...

[LMESTM]

+cc @apalmieriGH

[apalmieriGH]

cc @avilei

[avilei]

Hi,
please notice that on NUCLEO-F429ZI there is a HW between Ethernet and the BLE expansion board. The PA.7 pin is used both by the Ethernet interface and the BLE expansion board. This means that if you want to use both Ethernet and BLE, you need to either patch the boards or connect the BLE expansion board with jump-wires so that you can select other pins for the SPI interface (needed to communicate with the BlueNRG BLE chip.

Hope that helps,
Antonio

[avilei]

I meant there is a HW conflict between Ethernet and the BLE expansion board. And Ethernet support is enabled by default on NUCLEO-F429ZI mbed port.

[LMESTM]

@mbartling Hey - have you got any news about this issue ?
From @avilei explanations, you may deactivate Ethernet support in case you don't need it for your application. Is this something you have tried or could try ?

[mray190]

@LMESTM - Took over this bug report from @mbartling.

Made the hardware switch by moving zero resistor R4 to R6. Additionally removed the LED initialization from example code https://developer.mbed.org/teams/ST/code/BLE_HeartRate_IDB0XA1/. After both changes were made, the bluetooth interaction now works.

Did not have to disable the Ethernet in order to get it to work.

[LMESTM]

@mray19027 thanks a lot for the feedback
I don't think there is that can be done on mbed-os repo, if anything can be improved on documentation side, please let us know.
and shall we close this issue ?