nrf_spi_mngr_perform Keeps MISO Line Low

[aa]

Hi,

I'm working with the nrf52840 and spi mngr to talk to a SPI flash memory (AT25SF081). I use nrf_spi_mngr_perform to send a command to read the manufacturer ID

const uint8_t data[] = {0x9F};
uint8_t mnf_id[4] = {0x00, 0x00, 0x00, 0x00};
nrf_spi_mngr_transfer_t const transfer[] =
  {
    NRF_SPI_MNGR_TRANSFER(data, sizeof(data), response, sizeof(response))
  };

nrf_spi_mngr_perform(&m_nrf_spi_mngr, NULL, transfer, ARRAY_SIZE(transfer), NULL);

The device should reply with a known code {0x1F, 0x85, 0x01}, but instead I'm getting only the first and last byte: 0x1F, 0x00, 0x01

After a lot of debugging I discovered that If I disconnect the MISO line from the nRF52840-DK board, the correct sequence is actually being sent by the memory, which proves the app is the one

driving the line down just during the 2nd byte:

I already tried setting the NRFX_SPI_MISO_PULL_CFG flag to 3 (MISO pullup) and 0 (MISO no pull) without success (besides the line remaining high - when CFG = 3 - permanently when the transaction finishes.

I also tried changing the irq_priority during the configuration and also via SPI_DEFAULT_CONFIG_IRQ_PRIORITY without any success. This is my config:

static nrf_drv_spi_config_t const m_master_config =
{
	.sck_pin        = NRF_GPIO_PIN_MAP(1, 4),
	.mosi_pin       = NRF_GPIO_PIN_MAP(1, 1),
	.miso_pin       = NRF_GPIO_PIN_MAP(1, 2),
	.ss_pin         = NRF_GPIO_PIN_MAP(1, 3),			
	.irq_priority   = APP_IRQ_PRIORITY_LOWEST,
	.orc            = 0x00,
	.frequency      = NRF_DRV_SPI_FREQ_2M,
	.mode           = NRF_DRV_SPI_MODE_0,			
	.bit_order      = NRF_DRV_SPI_BIT_ORDER_MSB_FIRST
};

Thinking the problem was caused by initialising the module at the wrong time, I also tried calling it via app_sched_event_put(), but got the same results.

Am I doing something obviously wrong? Any advice would be greatly appreciated.

I'm using the SDK v15.3.0.

Thanks.

A.

[haakonsh]

I've got three thoughts:

1. The MISO pin is driven low somewhere else in your application.
   
   
2. There's an issue with the SPIM transfer buffers when they are not word-aligned to 32bits. 
   
   
3. There's a bug in the SPI manager library, try the SPIM driver and see if you get the same result. 

[aa]

haakonsh, thanks for your reply. 

1. Unlikely. I only have BLE + SPI working at this point. Already tried multiple pins for that line with the same results. Will try disabling all other peripherals and check again though.

2. Many memory chips out there use the same "1-byte command" approach. I can't believe I'm the first user trying to do this?

3. If that's was the case I imagine there would be tons of posts from people complaining about the same issue. I couldn't find any.

[aa]

On Point 1. I just tried disabling all the others peripherals (Radio, UART, I2C), same results.

[aa]

@haakonsh, any other thoughts?... Anyone?

[haakonsh]

I very much doubt it's the driver that's pulling the line low. My bet is on noise, try adding a 100ohm series resistor to the MISO and CLK lines. 

[aa]

haakonsh, thanks heaps for the advice; I can confirm that adding a 100ohm series resistor in the MISO line solves the problem! I was convinced the lines were noise-free.