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.
