NRF52840 SPIM3

[lpham]

Hi,

I am using the 2 NRF52840 boards, rev 1.  I am using SDK 15.2.  The first board is running the NRFX_SPIM example.  The second board is running the SPIS example.  The rx_delay is set to 0x02.

When I configured the SPIM to run at 4MHz.  The SPIM and SPIS sometimes get the correct message.  and sometimes get data value of all F's.

When I configured the SPIM to run at 32MHz.  The SPIM and SPIS received data is always incorrect.

Any ideas?  Has anyone tried using the NRFX_SPIM and SPIS example projects together?

Thanks,

SPIM configured to run at 4MHz result.  Below is the result from the SPIM.

0> <info> app: Transfer completed.
0> <info> app: Received:
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF |.....
0> <info> app: Transfer completed.
0> <info> app: Received:
0> <info> app: FF 4E 6F 72 64 69 63 31|.Nordic1
0> <info> app: 32 33 34 35 36 37 38 39|23456789
0> <info> app: 30 31 32 33 34 35 36 37|01234567
0> <info> app: 38 39 30 31 32 33 34 35|89012345
0> <info> app: 36 37 38 39 30 |67890
0> <info> app: Transfer completed.
0> <info> app: Received:
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF |.....
0> <info> app: Transfer completed.
0> <info> app: Received:
0> <info> app: FF 4E 6F 72 64 69 63 31|.Nordic1
0> <info> app: 32 33 34 35 36 37 38 39|23456789
0> <info> app: 30 31 32 33 34 35 36 37|01234567
0> <info> app: 38 39 30 31 32 33 34 35|89012345
0> <info> app: 36 37 38 39 30 |67890

Below is the result of the SPIM when configured to run at 32MHz.

0> <info> app: Transfer completed.
0> <info> app: Received:
0> <info> app: FF FF FF DF E5 C9 D3 C7|........
0> <info> app: 63 64 67 68 6A 6C 6E 38|cdghjln8
0> <info> app: 39 30 31 32 33 FF FF FF|90123...
0> <info> app: FF FF B9 B0 B1 B2 B3 B4|........
0> <info> app: B5 B6 B7 B8 B9 |.....
0> <info> app: Transfer completed.
0> <info> app: Received:
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF |.....

Below is the result of SPIS when configured to run at 32MHz.

Transfer completed

0> <info> app: 6F 72 64 69 63 31 32 33|ordic123
0> <info> app: 34 35 36 37 38 39 30 31|45678901
0> <info> app: 32 33 34 35 36 37 38 39|23456789
0> <info> app: 30 31 32 33 34 35 36 37|01234567
0> <info> app: 70 72 60 |pr`

Transfer completed
0> <info> app: 37 B9 32 34 B1 98 99 19|7.24....
0> <info> app: 9A 1A 9B 1B 9C 1C 98 18|........
0> <info> app: 99 19 9A 1A 9B 1B 9C 1C|........
0> <info> app: 98 18 99 19 9A 1A 9B 1B|........
0> <info> app: 9C 1C 98 |...

[hmolesworth]

That looks suspiciously like low drive issues, especially since traversing a significant number of mm from one board to another. I think the examples do not set high drive, so maybe try something like this after initialisation on all SCK CS and MOSI pins (6 pins in all):

    nrf_gpio_cfg(SCK_1_PIN,
                 NRF_GPIO_PIN_DIR_OUTPUT,
                 NRF_GPIO_PIN_INPUT_DISCONNECT,
                 NRF_GPIO_PIN_NOPULL,
                 NRF_GPIO_PIN_H0H1,       // Require High Drive low & high levels
                 NRF_GPIO_PIN_NOSENSE);

[lpham]

I am using the following PINs:

• SS - P0.14
• MISO - P0.26
• MOSI - P0.24
• SCK - P0.6

These PINs should support high drive mode.

In the SPIM project, I used "nrf_gpio_cfg" like you stated for SS, SCK, and MOSI.

In the SPIS project, I used "nrf_gpio_cfg" like you stated for the MISO.  The data looks very bad.  The number of bytes in the SPIS is correct.  The number of bytes in the SPIM includes an extra byte.

SPIM Outputs:

0> <info> app: Transfer completed.
0> <info> app: Received:
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF FF FF FF|........
0> <info> app: FF FF FF FF FF |.....
0> <info> app: Transfer completed.
0> <info> app: Received:
0> <info> app: FF E9 CD EE 4C 8D 2C 66|....L.,f
0> <info> app: 26 46 66 86 A6 C6 E7 07|&Ff.....
0> <info> app: 26 06 26 46 66 86 A6 C6|&.&Ff...
0> <info> app: E7 07 26 06 26 46 66 86|..&.&Ff.
0> <info> app: A6 C6 E7 07 26 |....&

SPIS Outputs:

Transfer completed.

0> <info> app: 73 7B 93 23 4B 19 89 91|s{.#K...
0> <info> app: 99 A1 A9 B1 B9 C1 C9 81|........
0> <info> app: 89 91 99 A1 A9 B1 B9 C1|........
0> <info> app: C9 81 89 91 99 A1 A9 B1|........
0> <info> app: B9 C1 C9 80 |....

Transfer completed.
0> <info> app: 73 7B 93 23 4B 19 89 91|s{.#K...
0> <info> app: 99 A1 A9 B1 B9 C1 C9 81|........
0> <info> app: 89 91 99 A1 A9 B1 B9 C1|........
0> <info> app: C9 81 89 91 99 A1 A9 B1|........
0> <info> app: B9 C1 C9 80 |....

[hmolesworth]

Ah, what's that P0.6 I see :-) have you checked pca10056.h and multiple  other places for stuff like this:

#define RX_PIN_NUMBER  8
#define TX_PIN_NUMBER  6 // ie P0.06
#define CTS_PIN_NUMBER 7
#define RTS_PIN_NUMBER 5

Also note there is probably a hardware connect to that pin on the nRF52DK

[hmolesworth]

Typo; I meant SPIM not PWM

[lpham]

I am able to get 16MHz clock working now.  I understand the settings better now.  At 32MHz the clock and the MISO data don't line up correctly.  I switched from mode0 to mode1, changed the rx_delay to align the data.  But now I am getting a bad SCK.  I think if I figure out the SCK issue then it will work at 32MHz.  Any idea why there's a hick up in the SCK?  Bad GPIO setting?

At 32MHz.  The Data from Master to Slave is good.  Data from Slave to Master is garbled up sometimes now.  At 16MHz, I am able to transfer 36 bytes of data between the two boards successfully.

[Jørgen Holmefjord]

Did you try using a different GPIO than P0.06 for SCK? This pin is by default used for UART peripheral and connected to interface MCU.

[hmolesworth]

On the nRF52DK pca10056 pin P0.06 - SCK in this case - is driving D17 and TxD; D17 may be unconnected but TxD is connected to MUX U5 and hence potentially to IMCU_RxD on the J-Link interface ATSAM3U. There is a cuttable link .SBS2 to remove that loading, which at 16MHz or 32MHz will be significant.