SPI Slave on STM32F4xx

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
RoMc_863046
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

Hello,

I am trying to configure SPI Slave on STM32F4xx in the Laird EWB Platform.  The Host MCU is STM32F412.

I have added SPI4 on the STM32 to the Wiced definitions in platform.c.  I can use this as SPI master without issues.

When I use the Wiced SPI Slave functions, I am getting a build errors.

build/laird.ampnet_app-LAIRD_EWB-ThreadX-NetX-SDIO/libraries/STM32F4xx.a(wiced_platform_common.o): In function `wiced_spi_slave_init':

C:\Data\AMP_WORK\WICED-Studio-6.6\43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/../wiced_platform_common.c:429: undefined reference to `platform_spi_slave_drivers'

collect2.exe: error: ld returned 1 exit status

Another developer had the same  issue some years ago. Here is a link to that thread.

SPI SLAVE

The Laird EWB platform has platform_spi_slave_init(...) in the platform file.

...WICED\platform\MCU\STM32F4xx\peripherals\platform_spi.c

This same source file has the functions I used for SPI master. 

What step am I missing to use this source for SPI slave?

Thank you,

-Rocko

Module

  Mfr     : Laird Connectivity

  P/N     : Sterling-EWB

  MCU     : STM32F412VEH6

  WLAN    : BCM4343W Wi-Fi CoB

  Antenna : chip

0 Likes
9 Replies
Murali_R
Moderator
Moderator
Moderator
250 sign-ins 250 replies posted 100 solutions authored

RoMc_863046

Since you say that the system is working fine as a master, I assume that the required changes have been made in the platform.h and the platform.c file and the issue is because there maybe some file inclusion that maybe missing.

Can you add $(NAME)_COMPONENTS += drivers/spi_slave in the platform.mk file and see if the build goes through?

If not, can you share the code that you are using so that I can reproduce the issue and see what is missing?

Thanks

0 Likes
lock attach
Attachments are accessible only for community members.
RoMc_863046
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

Hello MuraliR_36,

 

Adding $(NAME)_COMPONENTS += drivers/spi_slave in the platform.mk (laird_platform_targets.mk) did not have any affect.

However, I have resolved the compile issue.

I needed to add the following line to my platform.c file:

platform_spi_slave_driver_t platform_spi_slave_drivers[WICED_SPI_MAX];

 

I am now having an issue when data is sent from the WICED SPI slave to the SPI Master.  For a Master, I am using an Aardvark SPI USB Host Adapter from Total Phase.

This allows me to send and receive SPI data from a PC.  I am also monitoring the bus with a logic analyzer.

The slave buffer should be sending 8 bytes:

SPI Slave TX Data: 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

 

On the first attempt I receive 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x00 at the master.

The eighth byte is wrong.

On every attempt to receive after the first, I receive 0x88 0x11 0x22 0x33 0x44 0x55 0x66 0x77

As you can see, I receive the 8th byte from the packet before as the first byte. So, something is out of sequence.

 

RoMc_863046_0-1610112990437.png

 

 

Attached is my SPI source code as well as my platform.c and platform.h revisions.

 

Thank you,

-Rocko

0 Likes

Posting Murali's reply to Rocko...

I went over the code and I don’t think anything is wrong as such.

I believe this is more of a run time issue from what you had shared below since I see that an additional zero at the beginning is somehow causing an over run of 1 byte in each iteration.

Can you get me the print logs that have been provided in the code?

Can you add an additional printf() and print ‘buffer->data’ after memcpy( buffer->data, slave_tx_data, size_data ); just to be doubly sure that there is no issue in memcpy();

Also I see that SPI_SLAVE_TRANSFER_WRITE  is used in wiced_spi_slave_transfer_data(). But in /43xxx_Wi-Fi/WICED/platform/include/platform_peripheral.h; This is how it is defined.

typedef enum

{

    SPI_SLAVE_TRANSFER_WRITE, /**< SPI master writes data to the SPI slave device  */

    SPI_SLAVE_TRANSFER_READ   /**< SPI master reads data from the SPI slave device */

} platform_spi_slave_transfer_direction_t;

Can you change the SPI_SLAVE_TRANSFER_WRITE to SPI_SLAVE_TRANSFER_READ and check if it makes any difference?

 

Thanks and Regards

Murali

0 Likes

Posting Rocko's response to Murali...

Greg / Mruali,

 

I have added the printf() for ‘buffer->data’ after the memcpy.

Instead of clocking out ZERO’s from the master, I’m clocking out ‘0xAA 0xBB 0xCC 0xDD 0xEE 0xFF 0x44 0x55’

 

Here is the console output:

Starting WICED Wiced_006.006.000.0009

Platform LAIRD_EWB initialised

Started ThreadX v5.9

WICED_core Initialized

Initialising NetX v5.12

Creating Packet pools

WLAN MAC Address : C0:EE:40:70:35:61

WLAN Firmware    : wl0: Jun 18 2020 08:48:22 version 7.45.98.102 (r726187 CY) FWID 01-36dd36be

WLAN CLM         : API: 12.2 Data: Laird.SterlingEWB Compiler: 1.29.4 ClmImport: 1.39.1 Customization: v1 20/06/16 Creation: 2020-06-16 08:52:46

SPI4 Slave init OK

 

sizeof(slave_tx_data): [13]

buffer->data: 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

 

SPI Slave TX Data: 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

SPI Slave TX Data: 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

SPI Slave TX Data: 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

SPI Slave TX Data: 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

 

SPI Master Transaction Log:

GrCa_1363456_0-1610637453517.png

 

 

Changing the slave transfer direction in in wiced_spi_slave_transfer_data() from SPI_SLAVE_TRANSFER_WRITE to SPI_SLAVE_TRANSFER_READ is one of the first things I tried.

I believe SPI_SLAVE_TRANSFER_READ is require when sending data to the slave from a master.

Based on these results, it appears that WICED cannot simultaneously read from the slave as you clock data out (it’s not synchronous). 

 

For this example the Master clocks out ‘0xAA 0xBB 0xCC 0xDD 0xEE 0xFF 0x44 0x55’. 

If WICED were synchronous, I’d expect to be receiving ‘0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88’ as the master clocks.

 

Here is the console output:

Starting WICED Wiced_006.006.000.0009

Platform LAIRD_EWB initialised

Started ThreadX v5.9

WICED_core Initialized

Initialising NetX v5.12

Creating Packet pools

WLAN MAC Address : C0:EE:40:70:35:61

WLAN Firmware    : wl0: Jun 18 2020 08:48:22 version 7.45.98.102 (r726187 CY) FWID 01-36dd36be

WLAN CLM         : API: 12.2 Data: Laird.SterlingEWB Compiler: 1.29.4 ClmImport: 1.39.1 Customization: v1 20/06/16 Creation: 2020-06-16 08:52:46

SPI4 Slave init OK

 

sizeof(slave_tx_data): [13]

buffer->data: 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

 

SPI Slave TX Data: 0xaa 0xbb 0xcc 0xdd 0xee 0xff 0x44 0x55

SPI Slave TX Data: 0xaa 0xbb 0xcc 0xdd 0xee 0xff 0x44 0x55

SPI Slave TX Data: 0xaa 0xbb 0xcc 0xdd 0xee 0xff 0x44 0x55

SPI Slave TX Data: 0xaa 0xbb 0xcc 0xdd 0xee 0xff 0x44 0x55

 

SPI Master Transaction Log:

GrCa_1363456_1-1610637453521.png

 

 

Note, in the console output above, the data in the TX buffer is overwritten with data received.

When configured as SPI Slave, WICED uses a structure (platform_spi_slave_data_buffer_t) that only has one buffer used for either TX or RX based on the value of slave transfer direction in in wiced_spi_slave_transfer_data. 

When configured as SPI Master, WICED uses a structure (platform_spi_message_segment_t) that has both an RX and TX buffer.

 

Regards,

-Rocko

0 Likes
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

@Murali_R - Any thoughts on the last response?

0 Likes
RoMc_863046
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

@Murali_R ,

Do you have any thoughts on my latest response (posted by Greg) from Jan 14th?  Please let me know if you require additional details.

Thank you.

-Rocko

 

@GrCa_1363456 

@MichaelF_56 

0 Likes
Murali_R
Moderator
Moderator
Moderator
250 sign-ins 250 replies posted 100 solutions authored

@RoMc_863046 

As I said before, I don't think there is any issue with the code as such and as seen in the initial logs that you have given, the data transmitted is 'SPI Slave TX Data: 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88'. But somehow there seems to be a 0xFF appended in the last byte during the 1st transaction which is resulting in the observation that you have put out.

Let me try to reproduce the issue on my end. I plan to reproduce the issue using a BCM943438WCD1 as a spi slave and a suitable device as a SPI master.

I will let you know my findings once I have this done.

 

Thanks

lock attach
Attachments are accessible only for community members.

I'm adding this information to the Community to complete the record of this issue.

From Murali:
Murali is using an Arduino Mega as a SPI master and putting Rocko's code onto a BCM943438WCD1 (CYW43438 based kit) as the SPI slave to attempt to recreate the issue.

I tried to reproduce, but looks like I missed a critical component where the Arduino works at 5v and the 43438 board works at 3.3v and I don’t have a level shifter to get these to work together.
Can rocko get an oscilloscope trace for me to analyse and see if there is a synchronisation issue ?
Also I couldn’t figure out what was the logic behind this line
buffer_size = sizeof(wiced_spi_slave_data_buffer_t) - 1 + size_data;
Can rocko try varying this and see if it helps out?


From Rocko:
Attached are scope and logic analyzer captures.

As far as this line of code goes:
buffer_size = sizeof(wiced_spi_slave_data_buffer_t) - 1 + size_data;
I think I was manipulating the buffer size while trying to debug the issue. The following should be adequate.
buffer_size = sizeof(wiced_spi_slave_data_buffer_t) + size_data;
Adding or trimming the buffer by one had no effect.

Several images are attached. In sequence, they show the SPI story.

four_packets.png -> This shows that the MISO line is low prior to the first packet and is idle high on the rest.
first_packet.png -> MISO is idle low before the first packet
second_packet.png-> MISO is idle high before the second packet
after_second_packet -> MISO goes idle high 5.4ms after the second packet.
The logic analyzer capture titled "logic_capture.png" is the second SPI packet.

0 Likes

@Murali_R wrote:

Let me try to reproduce the issue on my end. I plan to reproduce the issue using a BCM943438WCD1 as a spi slave and a suitable device as a SPI master.

I will let you know my findings once I have this done.


What's your finding?