nRF52840 Dongle FATFS issue when SPIM and SPIS are configured at the same time

[BLaszlo]

Hello, 

I have been using nRF52840-DK and also nRF52840 Dongle for testing and I found an interesting behaviour when I established my test setup. The RF module acts as an SPI slave towards another MCU, and also acts as an SPI master towards a micro SD card extension. As far as I know most of the existing GPIO pins can be configured to be used as SPI pins so based on that my PIN layout is the following:

SPIM (micro SD card extension):

• SCK: P0.31
• MISO: P0.13
• MOSI: P0.15
• CS: P1.0

SPIS (another MCU):

• SCK: P1.10
• MOSI: P1.15
• MISO: P1.13
• CS: P0.2

Also there is an additional GPIO configured as output on P0.29.

I also set the MISO Pull configuration to pull-up because I read (https://devzone.nordicsemi.com/f/nordic-q-a/24334/fatfs-example-sdk14-0-0-not-working#post-id-163682) that it is needed for the fatfs library to work as expected for new generation micro SD cards.

The issue is when I execute my program the nRF52840-DK works perfectly and the data is written to the SD card always, but when I use the Dongle the data is usually not written (fatfs fails with disk initialization failure). It only happens when I use a new generation 32Gb U3 and U1 micro SD cards, the issue is not present for older versions (with 16Gb U1 works fine).

I tried to change the RF module (Dongle), cables, and tested the setup with 3 different kind of micro SD card extensions, for all of them I received the same result. Also tested the SPIM and SPIS separately and like that both works fine (even the fatfs example works flawlessly).

Is there any difference in the PIN configuration or setup between the nRF52840-DK and Dongle that might cause this issue? Or do you have any PIN layout recommendations that might solve this issue if I intend to use SPIM and SPIS at the same time for the nRF52840 Dongle?

Thank you in advance for your support!

[Simonr]

Hi

The following pins that you mention are only recommended to use as standard drive and low frequency I/Os while the radio is being used.

P0.31
P0.02
P1.10
P1.15
P1.13
P0.29

This is because they may interfere with the radio's performance if running at high frequencies. This should not be an issue if you're not using the radio though, I just thought I should mention it.

This seems very strange, as none of those pins should conflict with anything but the radio in both the DK and Dongle. Are you positive that all the pins are attached to the Dongle properly? One thing though. According to the FatFs documentation, it is limited to 4GB sizes, so that might be the issue, although that doesn't explain why it works on the DK and not the Dongle. A disk init failure from the SD card reader leads me to think that the SD card reader isn't properly connected to the Dongle. Are you able to provide any error code of some sort if you try debugging?

Best regards,

Simon

[BLaszlo]

Hello Simon,

 

Thank you for your answer, and actually it is good that you mentioned the radio performance interference because it is used too (however at the point where it fails the radio is just initialized).

My first guess was the faulty connection, but this was proven wrong by writing to an older 16Gb micro SD card without any problem.

Is it possible to have an SPIS and SPIM interface, along with the radio? And if yes, in the future we might decide to embed an nRF52840 based chip on a PCB where we are not limited to the Dongle pins. Is there any suggestion which pin configuration would be the most efficient in this case?

In the meantime I will try to find out the error code for the disk initialization failure for the Dongle, but without a debugger environment it is quite challenging.

 

Thank you again and best regards,

Bertalan

[Simonr]

Hi

Yes, it should absolutely be possible to use SPIS, SPIM, and the radio simultaneously. Just remember to have the SPIS and SPIM in different instances so they don't conflict with one another.

I would suggest starting with your DK to find suitable GPIOs for the SPIS and SPIM, as there are way more GPIOs available there. Here is a list of GPIOs that can be used in high drive/frequency mode without interfering with radio performance:

P0.04
P0.05
P0.06
P0.07
P0.08
P0.11
P0.12
P0.13
P0.14
P0.15
P0.16
P0.17
P0.18 (configurable as pin reset as well)
P0.19
P0.20
P0.21
P0.22
P0.23
P0.24
P0.25
P1.00
P1.08
P1.09

Regarding debugging on the Dongle, you should be able to do so by soldering a 10-pin header onto the P1 header footprint on the bottom side of the Dongle (see section 6.3.2 in the Dongle user guide or the Dongle programming tutorial for details).

Best regards,

Simon

[BLaszlo]

Hello Simon,

I started to test the high drive GPIOs, but I might be missing some configuration because if I reconfigure the pin connections of the micro SD extension it does not work at all. I configured the following pins:

• SCK: P0.20
• MOSI: P0.21
• MISO: P0.22
• CS: P0.23

I also tested several other high drive pins, but neither of them now working as expected. The HFCLK is started when I initialize the used clocks.

I saw that the SPIM driver has the following configuration:

    nrf_gpio_cfg(p_config->sck_pin,

                 NRF_GPIO_PIN_DIR_OUTPUT,

                 NRF_GPIO_PIN_INPUT_CONNECT,

                 NRF_GPIO_PIN_NOPULL,

                 NRF_GPIO_PIN_S0S1,

                 NRF_GPIO_PIN_NOSENSE);

Should I modify the 5th parameter to NRF_GPIO_PIN_H0H1 in order to make it work?

Also thank you for the suggestion of soldering a 2x5 pin connector on the Dongle, I will definitely try it later to troubleshoot the issue further.

Thank you in advance for your answer.

Br,

Bertalan

[Karl Ylvisaker]

Hello Bertalan,

Are you currently working on your DK, as suggested by Simon?
The pins you have selected - p.020 to p.023 - is already in use for the QSPI ( external memory ) on the DK. In order to use those pins as GPIO's you would have to cut and short the SolderBridges mentioned in the documentation.
You mention that you have tried several other pins, but none of the configurations have worked. Could you elaborate which configurations you have tried?

When you say that it did not work at all, are you testing the pin configurations with the fatfs example? I suggest using it as a base when changing the configuration, since you were able to verify that the example worked as expected earlier - this will make tracking and identifying issues much easier.

As Simon mentions, the dongle is a great companion when developing BLE applications - but it is usually best to start the development on the DK, since it has an onboard debugger and a much more broad connection interface.

Best regards,
Karl