SPI behaviour is random depending on the previous code

[TY]

Dear Nordic Team, Meanwhile, I've burned through a week finding a solution for this problem. Now I am out of ideas where to check for problems.

---

My application: I'm using an nRF52832-QFAABO 1639DE via SPI I am communication with a WiFi SoC (ATWINC1500-MR210PB). I am using the MQTT client from the IoT SDK and the Socket Library from the Atmel SDK.

SPI Pins:

AT_IQRN_PIN 10

AT_WAKE_PIN 11

AT_CLK_PIN 7

AT_MISO_PIN 5

AT_MOSI_PIN 6

AT_SS_PIN 4

AT_RESET_PIN 8

AT_CHIP_EN_PIN 9

[SDK11, GCC - 6.2 2016q4, No Soft Device, No Bootloader ]

---

The Atmel SDK gets access to the SPI via this function:

static sint8 spi_rw(uint8* pu8Mosi, uint8* pu8Miso, uint16 u16Sz)
{
    APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, pu8Mosi,(uint8)u16Sz, pu8Miso,
                                                                  (uint8)16Sz));
	return M2M_SUCCESS;
}

Everything works fine most of the time. However, since a few weeks, I am facing the problem that depending on where in my code I change things the SPI read returns rubbish. The weird part is that sometimes the things I change are not even getting executed because they are in functions which are needed after establishing the connection with the MQTT Broker.

For instance: The SPI config struct gets initialized with the default config

 (nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG(SPI_INSTANCE);)

Meaning that SPI MODE is set to Zero, however, when comment or uncomment the line where I set the spi_config.mode the SPI read behaviour is diffrent.

   spi_config.ss_pin 		= AT_SS_PIN;
	spi_config.sck_pin 		= AT_CLK_PIN;
	spi_config.mosi_pin		= AT_MOSI_PIN;
	spi_config.miso_pin 	= AT_MISO_PIN;
	spi_config.frequency	= NRF_SPI_FREQ_125K;
	//spi_config.mode			= NRF_SPI_MODE_0;

    nrf_gpio_cfg_input(AT_IQRN_PIN,NRF_GPIO_PIN_NOPULL);
	APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, NULL));

	APP_ERROR_CHECK(NRF_LOG_INIT());

I'll explain the effect to the end. The difference this line of code is causing is only in the location of the functions in the flash since it is only a few instructions. As you can see in this screenshot.

The Problem: In the picture below you can see the difference ( the white signal is the reference which works). After some back and forth sending commands and receiving the response, the Atmel Library wants to get the result of the DNS request which is a 68byte package with the URL at the beginning and the IP (int) to the end. This transaction fails as you can see in the picture the URL is not complete and the IP is Zero.

Things I have tested: I have verified the behaviour of all pins needed to control the WiFi SoC with an logic analyzer there is no difference to see. The arguments passed to SPI read function are the same in both cases (SPI clock is behaving normally)

I am not sure about this issue mentioned in this [Errata Attachment] (infocenter.nordicsemi.com/.../nRF52_PAN_109_add_v1.0.pdf) regarding the SPI. If I understand correctly this issue should be consistent meaning either it causes the WiFi library to fail or the implementation is not getting irritated by the Ghost Bytes.

Any suggestion is highly appreciated I have no idea what else can be wrong.

[TY]

Update:

I can cause the communication between WiFi SoC and nRF52 to fail. By changing the optimization flag.

Right now the code runs through more steps in the connection procedure to the broker when the O flag is set to 1.

However, I can cause this to happen by just changing random thinks in functions which are not even getting called. Thus, the only difference is the allocation in flash. Meaning functions get assigned to different addresses.

So my question how can this change the behaviour of the FW in such a way that that the SPI communication fails with WiFi SoC. If checked the commands I am sending to the WiFi SoC they seem OK and it already gets connected to the router and does get it's IP from DHCP. But after trying to close the SPI session the command gets acknowledged with random values from the WiFi SoC.

The only possible explanation I have is that the altered flash allocation changes the timing behaviour of the nRF52.

-Does anyone have an idea what could be wrong with the flash allocation? -Why does the linker actually puts malloc from the gcc libraries in the flash if I am not calling it? -Is there a possibility that I missed a setting regarding the boot loader or the SD which are not present

Solution:

docs.google.com/.../edit

[RK]

it's more likely that you have a bug somewhere which trashes memory and that's what's causing your problems.

Nothing else you write makes any sense really, flash placement isn't going to change the timing of anything by any appreciable difference and your comments about malloc .. I really don't know what you're even suggesting. Optimized code does run faster, but if the whole thing is properly interrupt driven, that's not going to be an issue.

Optimisation is pretty good at uncovering memory bugs.

[TY]

What I mean regarding the malloc thing is that I can see in the map file that malloc has been put on the flash although I am never calling it.

[bjorn-spockeli]

@timur(TY): What was the optimization level set to before you set it to 1? Was it level 3 and do you see any improvements if you set it to leve 0, i.e. none?

[TY]

@Bjørn Spockeli I was developing all the time with optimisation off, just after realising that removing source files from the makefile (which are not needed) also changed the behaviour I was playing around with the optimisation flag and just changed it from 0 to 1. @b I'll get a decent logic analyser next week to observe all pins off the WiFi SoC. Meanwhile, I am certain that the behaviour of the WiFi SoC is wrong however this is caused by the slightly altered FW on the nRF52 (optimisation or off).

I am using the NFC pins for SPI which re-configured at beginning of my main(). Is there any ***-up potential?

[bjorn-spockeli]

@timur: I agree with @RK that the flash placement should not affect the timing of any of the nRF52's peripherals. As long as you have configured the NFC pins to be normal GPIO pins using the UICR NFCPINS register, i.e. defined CONFIG_NFCT_PINS_AS_GPIOS in your preprocessor symbols you should not see any issues.