Configuring MISO pin for SPIM nrf52

[troglobyte]

Greetings I am working on an application that logs data to SPI flash device. I am having an issue where it appears that the pin configured as a MISO for SPIM is garbling up the flash device's responses. I have verified with a logic analyzer that the device response is correct when unloaded and gets corrupted when terminated into the Nordic development board (pca10040). I have noted the same behavior for all pins on the nrf52. I have also used a number of different flash devices (Adesto AT25XE021A type devices) all with the same result. After the spi peripheral is initialized, the application attempts to read the device ID from the flash module. The correct response should be 0x1F, 0x43, 0x01, 0x00 but instead I read 0x1E, 0x08, 0x00, 0x00...

I have included my init code for inspection and have also noted that there is an errata where the Pin CNF gets reset whenever the device goes to sleep when in debug interface mode.

Here is how my pins are defined in nrf_drv_config.h...

#define SPI1_ENABLED 1

#if (SPI1_ENABLED == 1)
#define SPI1_USE_EASY_DMA 1

#define SPI1_CONFIG_SCK_PIN         25
#define SPI1_CONFIG_MOSI_PIN        23
#define SPI1_CONFIG_MISO_PIN        24
#define SPI1_CONFIG_IRQ_PRIORITY    APP_IRQ_PRIORITY_LOW

#define SPI1_INSTANCE_INDEX (SPI0_ENABLED)
#endif

This is the inline function called to configure the GPIO for the MISO input...

__STATIC_INLINE void nrf_gpio_cfg_input(uint32_t pin_number, nrf_gpio_pin_pull_t pull_config) {
    nrf_gpio_cfg(
            pin_number,
            NRF_GPIO_PIN_DIR_INPUT,
            NRF_GPIO_PIN_INPUT_CONNECT,
            pull_config,
            NRF_GPIO_PIN_S0S1,
            NRF_GPIO_PIN_NOSENSE); }

I have verified that the correct code is being called during initialization (SPI Master mode code) and am using the latest SDK code implementing the spi driver.

Other than the above mentioned errata, what could be causing the MISO signal to act as though it is being driven by the nrf52 even though it is configured as an input?

Any info would be appreciated!

Trog

[troglobyte]

Ok I believe that I have discovered what the core issue is. As a nrf52 newbie, I could see how this could happen but want to caution others new to the part... Ultimately what fixed my problem was running the "nrf Go Studio" application and erasing the device. As this device contains a "soft core" if one attempts to run one of the soft device application examples without first programming the soft device, the nrf52 can get into a corrupt state. At some point I believe that I attempted to do exactly that and it screwed up most of the pins on the device. I have been working on this on and off for the past few weeks. Ultimately my client who I am doing my first project on nrf52 for, alerted me to this issue and I was able to fix it.

[troglobyte]

I was about to do the same thing...see my answer below...

[RK]

No you can't 'get the nrf52 into a corrupt state' nor can you 'screw up most of the pins' nor does it have a 'soft core', I'm afraid most of what you've written is completely incorrect.

If you erase the softdevice and try to run a softdevice application then the device does completely absolutely nothing at all because there is no code for it to run because it was erased. It will go directly to the hardfault handler on reset, not run any of your application code or do anything useful at all. So if it was running your app at all, then you had the softdevice loaded. Although it's quite possible you loaded the wrong softdevice and got very random behaviour.

Happy to hear that you are working again, but your understanding of why is, I'm afraid, just wrong.

[troglobyte]

I would agree that my understanding of the device is limited at this time. To be clear, I received the development board in an unknown state from my client...I had no idea what soft device was loaded (nor what a soft device was for that matter...). I started with one of the non-BLE examples and got the TWI peripheral working without problems. Once I tried to add a SPIM peripheral was where the problems started...I am afraid I don't see much difference between "screwing up the pins" vs "random behaviour" however... My point is that developers new to the part should be aware of the nRF Go Studio utility... t

[Sir Oslay]

I cannot replicate your solution. I tried erasing the entire device and reflashing using both nrfjprog and nRFGo without success. I also tried manually changing the GPIO config (pullup, pulldown, etc.) in the PIN_CFG register with no success, so I don't understand how reflashing the soft device could make any difference. At the moment, my project is not using a soft device (and therefore not flashing it), but honestly that shouldn't matter. The SPI code should work regardless of whether or not the soft device is present. I'm going to stick with the solution I found.