This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52840 SPIM3

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 |...

Parents
  • 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);
    

  • 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 |....

Reply
  • 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 |....

Children
  • Did you try adding the code I posted above after your initialisation of the PWM driver? The reason for this is that the library SPI code does not use high-strength port pin drive, which can lead to soggy signals on SPI CLK, CS and MOSI outputs. That's actually 4 output drives which you can drive harder, SCK, CS and MOSI from the master, and the returned MISO driven by the slave. Soggy signals (ie low drive into a load) can cause the type of errors you are seeing.

    This code must be added for all 4 signals after the initialisation, as otherwise this code would be eclipsed. If you already tried that then maybe that's not the issue.

        pwm_init();
        // Now boost signal strength
        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);
        nrf_gpio_cfg(CS_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);
        nrf_gpio_cfg(MOSI_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);
    

  • I added the code you suggested after the function, "nrfx_spim_init".  There's no PWM usage in the SPIM and SPIS example projects.  

    The code works at low speed like 250KHz.  But at higher speed bytes the data received is incorrect.

  • 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

  • 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.

Related