NRF52840 SPIM3

RE: NRF52840 SPIM3

hmolesworth — Thu, 21 Feb 2019 16:53:47 GMT

Thanks for posting the results; given that the implied SPIS figure is only about 8MHz it's pretty impressive we can use 16MHz.

So I have an idea how you can get 64MHz SPI between 2 x nRF52840 DK boards, any interest in that? The trick is to use QSPI on the master, and 4 x SPIS on the slave. The 4 x Slave SPI all share SCK, MOSI and CS input signals, but each SPI MISO connects to one of the QSPI inputs on the master. Should work .. not tried it yet though. Our requirement is to get data off as fast as possible, and 64MHz is pretty fast.. QSPI Master is rated at 32MHz, but as we have found only 16MHz is usable on SPIS, so 4 x 16=64MHz :-)

I should add that we don't care about having to de-interlace the data, as it ends up on a much faster desktop.

RE: NRF52840 SPIM3

lpham — Thu, 21 Feb 2019 16:36:34 GMT

Thank you for everyone help.

At this point, I can only get 2 NRF52840 boards to work at 16MHz reliably. At 32MHz, the SPIM works good, but the SPIS MISO signal get corrupted. I am not sure it's a driver issue or hardware limitation at this point.

Below is the performance result that I measured.

Nordic NRF52840 16MHz Performance Results

29.9	Hz Frame
65535	bytes per frame
1959496.5	byte per second
600	us frame gap

I wish I can get the 32MHz working too. It would probably also increase the throughput by double.

Overall the performance is decent and it's probably the best SPI I have seen.

Thank you again for everyone help.

RE: NRF52840 SPIM3

lpham — Tue, 19 Feb 2019 22:40:45 GMT

I got the same results.

Thanks for trying it out. I am not sure why the MISO signal is bad.

RE: NRF52840 SPIM3

hmolesworth — Tue, 19 Feb 2019 22:36:42 GMT

I tried with out-of-box software on 2 x pca10056 nRF52 DKs SDK 15.2.0 and get good operation at 8MHz and 16MHz provided the hardware CS is disabled; the issue seems to be too short a setup time between /CS and SCK going active. It partially works at 32MHz, but every other packet gets slightly damaged. SPIM:

// This is working reliably at 16MHz, SPIM to SPIS both directions
// Only change is to SPIM, but SPIS works better in release mode
    nrfx_spim_config_t spi_config = NRFX_SPIM_DEFAULT_CONFIG;
    spi_config.frequency      = NRF_SPIM_FREQ_16M;   // <======== !
    spi_config.ss_pin         = NRFX_SPIM_SS_PIN;
    spi_config.miso_pin       = NRFX_SPIM_MISO_PIN;
    spi_config.mosi_pin       = NRFX_SPIM_MOSI_PIN;
    spi_config.sck_pin        = NRFX_SPIM_SCK_PIN;
    spi_config.dcx_pin        = NRFX_SPIM_DCX_PIN;
    spi_config.use_hw_ss      = false; //true;       // <======== !
    spi_config.ss_active_high = false;
    spi_config.mode           = NRF_SPIM_MODE_0;
    spi_config.rx_delay       = 0x02;
    spi_config.ss_duration    = 0x02;

    APP_ERROR_CHECK(nrfx_spim_init(&spi, &spi_config, spim_event_handler, NULL));

    // High power output pins
    nrf_gpio_cfg(NRFX_SPIM_SS_PIN,
                 NRF_GPIO_PIN_DIR_OUTPUT,
                 NRF_GPIO_PIN_INPUT_DISCONNECT,
                 NRF_GPIO_PIN_NOPULL,
                 NRF_GPIO_PIN_H0H1,       // Require High Drive high/low level
                 NRF_GPIO_PIN_NOSENSE);

    // High power output pins
    nrf_gpio_cfg(NRFX_SPIM_MOSI_PIN,
                 NRF_GPIO_PIN_DIR_OUTPUT,
                 NRF_GPIO_PIN_INPUT_DISCONNECT,
                 NRF_GPIO_PIN_NOPULL,
                 NRF_GPIO_PIN_H0H1,       // Require High Drive high/low level
                 NRF_GPIO_PIN_NOSENSE);

    // High power output pins
    nrf_gpio_cfg(NRFX_SPIM_SCK_PIN,
                 NRF_GPIO_PIN_DIR_OUTPUT,
                 NRF_GPIO_PIN_INPUT_DISCONNECT,
                 NRF_GPIO_PIN_NOPULL,
                 NRF_GPIO_PIN_H0H1,       // Require High Drive high/low level
                 NRF_GPIO_PIN_NOSENSE);

    NRF_LOG_INFO("NRFX SPIM example started.");

Note SPIS works better if compiled in Release build or with better optimisation, SPIS:

    nrf_drv_spis_config_t spis_config = NRF_DRV_SPIS_DEFAULT_CONFIG;
    spis_config.csn_pin               = APP_SPIS_CS_PIN;
    spis_config.miso_pin              = APP_SPIS_MISO_PIN;
    spis_config.mosi_pin              = APP_SPIS_MOSI_PIN;
    spis_config.sck_pin               = APP_SPIS_SCK_PIN;
    spis_config.mode                  = NRF_SPIS_MODE_0;

    APP_ERROR_CHECK(nrf_drv_spis_init(&spis, &spis_config, spis_event_handler));

    // High power output pins
    nrf_gpio_cfg(APP_SPIS_MISO_PIN,
                 NRF_GPIO_PIN_DIR_OUTPUT,
                 NRF_GPIO_PIN_INPUT_DISCONNECT,
                 NRF_GPIO_PIN_NOPULL,
                 NRF_GPIO_PIN_H0H1,       // Require High Drive high/low level
                 NRF_GPIO_PIN_NOSENSE);

RE: NRF52840 SPIM3

lpham — Tue, 19 Feb 2019 21:47:50 GMT

I am using MODE0.

I pulldown MOSI, MISO, SCK. I pullup CS. I applied the change to both the SPIM and SPIS projects.

It didn't solve the problem with the MISO signal.

RE: NRF52840 SPIM3

wpaul — Tue, 19 Feb 2019 21:15:51 GMT

This is just a guess, but have you tried enabling the internal pullups for the SPI pins? (I see NOPULL in the code snipped above, so I suspect not.)

I have a project where I'm using the high speed SPI bus at 32MHz for an ILI9341 display. I'm able to correctly do reads and writes of its video memory. (I don't actually use the read memory feature much, but I did test it at one point just as a sanity check.)

-Bill

RE: NRF52840 SPIM3

lpham — Tue, 19 Feb 2019 20:26:42 GMT

I looked at all the available GPIOs that support the high drive mode, and tried them out for the MISO but they all showed the same behavior.

I shorted the SB20, and cut SB10 to use P0.23 but it also exhibit the same behavior as other GPIOs.

Since P0.27 worked good, I swapped the MISO and MOSI but the MISO still shows bad data output.

RE: NRF52840 SPIM3

lpham — Tue, 19 Feb 2019 18:38:51 GMT

I also switched to P1.15 earlier but it had the same behavior.

RE: NRF52840 SPIM3

hmolesworth — Tue, 19 Feb 2019 18:37:15 GMT

MISO is P0.26 and connects to SDA which has a 4k7 pull-up R52 on the Mux U7 n/c and goes to several connections; maybe the capacitive loading is too high and a different (cleaner) pin would be better.

RE: NRF52840 SPIM3

lpham — Tue, 19 Feb 2019 18:15:44 GMT

I ended up moving the GPIOs.

spis_config.sck_pin = 2;
spis_config.mosi_pin = 27;
spis_config.miso_pin = 26;
spis_config.csn_pin = 47;

But the data out of the SPIS is bad.

SCK is good.
MOSI is good.
CS is good.
MISO is bad.

RE: NRF52840 SPIM3

hmolesworth — Tue, 19 Feb 2019 16:50:00 GMT

Nope, that won't help :-) here are the hardware design files in case you don't have them; there is a detailed schematic burried in there:

nrf52840 DK Hardware Files

Edit: They've moved, sorry .. I have trouble using the new info center but they are there somewhere ..

Not schematics, but close to what you need:

Updated link but not full schematics

RE: NRF52840 SPIM3

lpham — Tue, 19 Feb 2019 16:31:31 GMT

I updated my PINs last night. I am using the following PINs:

spis_config.sck_pin = 5;
spis_config.mosi_pin = 6;
spis_config.miso_pin = 7;
spis_config.csn_pin = 8;

RE: NRF52840 SPIM3

hmolesworth — Tue, 19 Feb 2019 16:27:14 GMT

Also note P0.14 is driving LED2, P0.24 connected to BUTTON4 and P0.26 to MUX U7; all these increase capacitive loading.

RE: NRF52840 SPIM3

hmolesworth — Tue, 19 Feb 2019 16:22:08 GMT

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.

RE: NRF52840 SPIM3

Jørgen Holmefjord — Tue, 19 Feb 2019 10:22:37 GMT

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.

RE: NRF52840 SPIM3

lpham — Mon, 18 Feb 2019 23:48:16 GMT

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.

RE: NRF52840 SPIM3

Jørgen Holmefjord — Mon, 18 Feb 2019 21:20:28 GMT

Hi,

The SPIS peripheral have a minimum clock input period of 125 ns, or 8 MHz, running it on 32 MHz will not work.

Best regards,
Jørgen

RE: NRF52840 SPIM3

hmolesworth — Mon, 18 Feb 2019 20:07:57 GMT

Typo; I meant SPIM not PWM

RE: NRF52840 SPIM3

hmolesworth — Mon, 18 Feb 2019 20:04:23 GMT

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

RE: NRF52840 SPIM3

lpham — Mon, 18 Feb 2019 20:03:46 GMT

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.

RE: NRF52840 SPIM3

hmolesworth — Mon, 18 Feb 2019 19:43:40 GMT

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

RE: NRF52840 SPIM3

lpham — Mon, 18 Feb 2019 19:16:25 GMT

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

RE: NRF52840 SPIM3

hmolesworth — Mon, 18 Feb 2019 18:20:18 GMT

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