SPI communication problem

RE: SPI communication problem

Alan Klimala — Tue, 02 Apr 2019 06:10:56 GMT

Thanks for clarification :)

RE: SPI communication problem

hmolesworth — Fri, 29 Mar 2019 15:08:24 GMT

You're welcome. As an aside, the reason this happened is that particular part is extremely fast so any minor high-frequency noise or slow rise/fall time on the rising or falling clock edge can be interpreted as a much faster multiple clock transition than the nominal 125kHz clock; the 'scope traces do not show this as the clock is so slow, but if the time-axis resolution were set to (say) 10nSec per division the soggy slope of the clock edge would be clearly seen. Increasing the drive sharpens up the edges and reduces this rise/fall time..

RE: SPI communication problem

Alan Klimala — Fri, 29 Mar 2019 08:15:41 GMT

Thank you hmolesworth !! Additional GPIOs configuration solved the problem.

RE: SPI communication problem

Alan Klimala — Fri, 29 Mar 2019 07:59:41 GMT

Sorry for late answer, I wasn't at office last two days. I tested all options but communication is still wrong. The only change is the response, but it might be connected to the fact that I switched tfrom nrfx_spi to nrfx_spim driver. Please take a look at screenshots below.

1. With NRF_GPIO_PIN_NOPULL

2. With NRF_GPIO_PIN_PULLDOWN

3. With NRF_GPIO_PIN_PULLUP

RE: SPI communication problem

Nguyen Hoan Hoang — Thu, 28 Mar 2019 08:12:42 GMT

The clock is always nice sine it is generated by the master. Yet, I have encountered many flash chips that do respond well under 1M. Don' t remember which one.

RE: SPI communication problem

Alan Klimala — Thu, 28 Mar 2019 08:06:41 GMT

Hi :)
Thank you for your input. The problem is that I can communicate with the device using exactly the same SPI configuration when using STM32 as a host controller. I know that 125K is a little bit slow and I do not plan to use it in production environment (it will be 1M at least). I just set 125K to have a nice looking clock signal, thus show communication on DSO clearly.

RE: SPI communication problem

Nguyen Hoan Hoang — Thu, 28 Mar 2019 00:30:30 GMT

I see that you are configuring the SPI freq at 125K. This will not work for many Flash devices. Min would be 1M but some flash would need 4M. So try at 4M first to see if you can read the ID.

RE: SPI communication problem

hmolesworth — Wed, 27 Mar 2019 15:35:58 GMT

I would try increasing the SPI clock frequency to at least 1MHz and boosting the drive of the three output signals to the flash; later on you can always investigate reducing drive strength again. Insert this after configuring SPI:

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

I would also reconsider your pin choice, especially when using much higher clock speeds:

4.3.1 GPIO located near the radio
Radio performance parameters, such as sensitivity, may be affected by high frequency digital I/O with large sink/source current close to the Radio power supply and antenna pins.
Table 5: GPIO recommended usage for QFN48 package on page 17 and Table 6: GPIO recommended usage for WLCSP package on page 17 identify some GPIO that have recommended usage guidelines to maximize radio performance in an application.
Table 5: GPIO recommended usage for QFN48 package
Pin GPIO
27 P0.22
28 P0.23
29 P0.24
37 P0.25
38 P0.26
39 P0.27
40 P0.28
41 P0.29
42 P0.30
43 P0.31

RE: SPI communication problem

Jørgen Holmefjord — Wed, 27 Mar 2019 12:03:09 GMT

Can you try changing the NRFX_SPIM_MISO_PULL_CFG in sdk_config.h? It is strange that the device does not respond with the same output when it receive the same command on MOSI line.

RE: SPI communication problem

Alan Klimala — Tue, 26 Mar 2019 13:50:28 GMT

Hi Jørgen,
Unfortunatelly the result is exactly the same. Take a look on a screenshot below:

RE: SPI communication problem

Jørgen Holmefjord — Tue, 26 Mar 2019 10:27:02 GMT

It looks like you are writing more bytes than necessary. If you want to write a single byte and receive 3 bytes after this, I would recommend using the following code:

uint8_t txBuf[] =
{
	0x9F
};

uint8_t rxBuf[4] = { 0 };

AT25SF041_bXferBytesLL(txBuf, 1, rxBuf, 4);

The peripheral will send out "dummy bytes" to read the following bytes into the RX buffer, you just need to ignore the byte received while transmitting the first byte.

RE: SPI communication problem

Alan Klimala — Mon, 25 Mar 2019 07:35:57 GMT

Hi Jørgen,

1. When I'm sending Read Manufacturer and Device (0x9F) command I call transfer function using such a code:

uint8_t txBuf[] =
{
	0x9F,
	0xFF,
	0xFF,
	0xFF
};

uint8_t rxBuf[6] = { 0 };

AT25SF041_bXferBytesLL(txBuf, 6, rxBuf, 6);

But as can be seen on the screenshot below I got wrong answer (should be 0x1F 0x84 0x01).

Doing the same with STM32 processor gives communication like on screenshot below:

2. When I'm sending Read ID (0x90) command I call transfer function using such a code:

uint8_t txBuf[] =
{
	0x90,
	0x00,
	0x00,
	0x00,
	0xFF,
	0xFF
};
uint8_t rxBuf[6] = { 0 };

AT25SF041_bXferBytesLL(txBuf, 6, rxBuf, 6);

And again the result is not as expected (should be 0x1F 0x12):

When I use STM32 I get:

My SPI configuration from sdk_config.h is as follows:

// <e> NRFX_SPI_ENABLED - nrfx_spi - SPI peripheral driver
//==========================================================
#ifndef NRFX_SPI_ENABLED
#define NRFX_SPI_ENABLED 1
#endif
// <q> NRFX_SPI0_ENABLED  - Enable SPI0 instance
 

#ifndef NRFX_SPI0_ENABLED
#define NRFX_SPI0_ENABLED 1
#endif

// <q> NRFX_SPI1_ENABLED  - Enable SPI1 instance
 

#ifndef NRFX_SPI1_ENABLED
#define NRFX_SPI1_ENABLED 0
#endif

// <q> NRFX_SPI2_ENABLED  - Enable SPI2 instance
 

#ifndef NRFX_SPI2_ENABLED
#define NRFX_SPI2_ENABLED 0
#endif

// <o> NRFX_SPI_MISO_PULL_CFG  - MISO pin pull configuration.
 
// <0=> NRF_GPIO_PIN_NOPULL 
// <1=> NRF_GPIO_PIN_PULLDOWN 
// <3=> NRF_GPIO_PIN_PULLUP 

#ifndef NRFX_SPI_MISO_PULL_CFG
#define NRFX_SPI_MISO_PULL_CFG 1
#endif

// <o> NRFX_SPI_DEFAULT_CONFIG_IRQ_PRIORITY  - Interrupt priority
 
// <0=> 0 (highest) 
// <1=> 1 
// <2=> 2 
// <3=> 3 
// <4=> 4 
// <5=> 5 
// <6=> 6 
// <7=> 7 

#ifndef NRFX_SPI_DEFAULT_CONFIG_IRQ_PRIORITY
#define NRFX_SPI_DEFAULT_CONFIG_IRQ_PRIORITY 6
#endif

// <e> NRFX_SPI_CONFIG_LOG_ENABLED - Enables logging in the module.
//==========================================================
#ifndef NRFX_SPI_CONFIG_LOG_ENABLED
#define NRFX_SPI_CONFIG_LOG_ENABLED 0
#endif
// <o> NRFX_SPI_CONFIG_LOG_LEVEL  - Default Severity level
 
// <0=> Off 
// <1=> Error 
// <2=> Warning 
// <3=> Info 
// <4=> Debug 

#ifndef NRFX_SPI_CONFIG_LOG_LEVEL
#define NRFX_SPI_CONFIG_LOG_LEVEL 3
#endif

// <o> NRFX_SPI_CONFIG_INFO_COLOR  - ANSI escape code prefix.
 
// <0=> Default 
// <1=> Black 
// <2=> Red 
// <3=> Green 
// <4=> Yellow 
// <5=> Blue 
// <6=> Magenta 
// <7=> Cyan 
// <8=> White 

#ifndef NRFX_SPI_CONFIG_INFO_COLOR
#define NRFX_SPI_CONFIG_INFO_COLOR 0
#endif

// <o> NRFX_SPI_CONFIG_DEBUG_COLOR  - ANSI escape code prefix.
 
// <0=> Default 
// <1=> Black 
// <2=> Red 
// <3=> Green 
// <4=> Yellow 
// <5=> Blue 
// <6=> Magenta 
// <7=> Cyan 
// <8=> White 

#ifndef NRFX_SPI_CONFIG_DEBUG_COLOR
#define NRFX_SPI_CONFIG_DEBUG_COLOR 0
#endif

// </e>

// </e>

Can you please help me somehow? The problem is that I have already tested three differen SPI FLASH chips and had preety same problems with each of them.

RE: SPI communication problem

Jørgen Holmefjord — Fri, 22 Mar 2019 14:21:34 GMT

Hi,

What ID are you reading, and what do you expect? What parameters do you pass to the function AT25SF041_bXferBytesLL() when you want to read the ID?

Best regards,
Jørgen