DA1468x crash when connecting SPI device on certain pins

9 posts / 0 new
Last post
david_33021
Offline
Last seen: 1 month 1 week ago
Joined: 2015-07-28 15:10
DA1468x crash when connecting SPI device on certain pins

Hi,

In our custom PCB, we're connecting a Dialog DA1468x to an ST Micro LSM6DSL using SPI. We created a first prototype PCB, "Proto1", and everything worked great. We've recently created a second prototype PCB, "Proto2", which connects the LSM6DSL to different pins on the DA1468x, and the 1468x now crashes on boot.

I'm able to reproduce the problem using the pxp_reporter sample from the 1.0.12.1078 SDK and a 1468x Pro development kit with a DA14681 in the AQFN package.

Pin connections as per our Proto1 PCB (works ok)

DA1468x SPI1 CLK: P1_3 -> LSM6DSL SCL
DA1468x SPI1 DI: P0_7 -> LSM6DSL SDO
DA1468x SPI1 DO: P2_3 -> LSM6DSL SDA
DA1468x CS: P4_7 -> LSM6DSL CS

Pin connections as per our Proto2 PCB (crashes on boot)

DA1468x SPI1 CLK: P4_1 -> LSM6DSL SCL
DA1468x SPI1 DI: P1_7 -> LSM6DSL SDO
DA1468x SPI1 DO: P1_2 -> LSM6DSL SDA
DA1468x CS: P3_0 -> LSM6DSL CS

In both examples,

DA1468x 1V8P -> LSM6DSL VDD
DA1468x 1V8P -> LSM6DSL VDDIO
DA1468x GND -> LSM6DSL GND

To reproduce the problem, connect the Pro DK to the LSM6DSL as per one of the configurations above, then modify the pxp_reporter software as follows:

1. Start with the pxp_reporter sample from the 1.0.12.1078 SDK
2. Add the following defines to custom_config_qspi_suota.h:

#define dg_configUSE_HW_SPI (1)
#define dg_configSPI_ADAPTER (1)
#define dg_configPOWER_1V8P (1)

3. Add a platform_devices.h file to the config directory and define an SPI bus and device:

SPI_BUS(SPI1)

SPI_SLAVE_DEVICE(
SPI1, MY_LSM6DSL,
HW_GPIO_PORT_4, HW_GPIO_PIN_7, // Proto1 - ok
// HW_GPIO_PORT_3, HW_GPIO_PIN_0, // Proto2 - crashes
HW_SPI_WORD_8BIT, HW_SPI_POL_HIGH, HW_SPI_PHA_MODE_1,
HW_SPI_FREQ_DIV_2, -1);

SPI_BUS_END

4. In the periph_init function in main.c, configure pins for SPI:

#if 1

// Proto1 - ok
#define SPI_CLK_PORT HW_GPIO_PORT_1
#define SPI_CLK_PIN HW_GPIO_PIN_3
#define SPI_DI_PORT HW_GPIO_PORT_0
#define SPI_DI_PIN HW_GPIO_PIN_7
#define SPI_DO_PORT HW_GPIO_PORT_2
#define SPI_DO_PIN HW_GPIO_PIN_3
#define LSM6DSL_CS_PORT HW_GPIO_PORT_4
#define LSM6DSL_CS_PIN HW_GPIO_PIN_7

#else

// Proto2 - crash on boot
#define SPI_CLK_PORT HW_GPIO_PORT_4
#define SPI_CLK_PIN HW_GPIO_PIN_1
#define SPI_DI_PORT HW_GPIO_PORT_1
#define SPI_DI_PIN HW_GPIO_PIN_7
#define SPI_DO_PORT HW_GPIO_PORT_1
#define SPI_DO_PIN HW_GPIO_PIN_2
#define LSM6DSL_CS_PORT HW_GPIO_PORT_3
#define LSM6DSL_CS_PIN HW_GPIO_PIN_0

#endif

hw_gpio_configure_pin(SPI_CLK_PORT, SPI_CLK_PIN,
HW_GPIO_MODE_OUTPUT, HW_GPIO_FUNC_SPI_CLK, 1);
hw_gpio_configure_pin_power(SPI_CLK_PORT, SPI_CLK_PIN,
HW_GPIO_POWER_VDD1V8P);

hw_gpio_configure_pin(SPI_DI_PORT, SPI_DI_PIN,
HW_GPIO_MODE_INPUT, HW_GPIO_FUNC_SPI_DI, 1);
hw_gpio_configure_pin_power(SPI_DI_PORT, SPI_DI_PIN,
HW_GPIO_POWER_VDD1V8P);

hw_gpio_configure_pin(SPI_DO_PORT, SPI_DO_PIN,
HW_GPIO_MODE_OUTPUT, HW_GPIO_FUNC_SPI_DO, 1);
hw_gpio_configure_pin_power(SPI_DO_PORT, SPI_DO_PIN,
HW_GPIO_POWER_VDD1V8P);

hw_gpio_configure_pin(LSM6DSL_CS_PORT, LSM6DSL_CS_PIN,
HW_GPIO_MODE_OUTPUT, HW_GPIO_FUNC_GPIO, 1);
hw_gpio_configure_pin_power(LSM6DSL_CS_PORT, LSM6DSL_CS_PIN,
HW_GPIO_POWER_VDD1V8P);

With the pin assignments from our old Proto1 PCB, the pxp_reporter app runs fine on the Pro DK connected to the LSM6DSL. If you change to the new pin assignments from our Proto2 PCB, the pxp_reporter app crashes on boot.

Here are a few more things I've found:

1. If I comment out #define dg_configPOWER_1V8P, it runs without crashing
2. If I don't connect the chip select line to the LSM6DSL, it survives boot without crashing

Here are some questions:

1. Are only certain pins on the 1468x available for SPI?
2. Am I forgetting to configure something on the 1468x in order to use SPI correctly?
3. I might be able to avoid the crash if I can set up the pin on the 1468x we're using as "SPI chip select" as an output (instead of the default input-pulldown) during boot. Is this possible?
4. Another workaround might be to delay staring 1V8P until after boot completes (and periph_init has had a chance to set up the chip select pin as an output). Is there an API I can call that enables 1V8P at runtime?

Thank you very much,
David

Device: 
MT_dialog
Offline
Last seen: 1 week 10 hours ago
Staff
Joined: 2015-06-08 11:34
Hi david_33021,

Hi david_33021,

1) No, there is no special limitation on the pins one can use for the SPI interface, all the pins can be configured and be used for the SPI interface (besides a few special pins like the first pins of the P0 port which are used for the QUAD SPI for example). I tested having the P3_0 as a CS on a SPI device didn't see any issues on my side. Perhaps you could try doing the same thing with a different SPI peripheral and check if you can replicate the issue.

2) No i dont see anything missing from the configuration in order to use the SPI.

3) You can burn the TCS flags in the OTP header in order to have the GPIO in different configurations while booting, but something else should be the case in your issue. 

4) The 1V8P is configured active when the bootloader is running, so no you wont be able to do that.

Regarding your issue, can you please check the voltage on 1V8P while the device boots up and check if there are any voltage dives on the rail ? and also do you have a pullup on the CS of the device ?

Thanks MT_dialog

david_33021
Offline
Last seen: 1 month 1 week ago
Joined: 2015-07-28 15:10
Hi MT_dialog,

Hi MT_dialog,

Thanks very much for your reply. I'll try a different SPI peripheral and also check the voltage on 1V8P during boot as you suggest.

We have not added an external pull up on our CS line to the device, but I checked the LSM6DSL's data sheet and the LSM6DSL does have an internal pull up on the CS line.

Thanks,
David

david_33021
Offline
Last seen: 1 month 1 week ago
Joined: 2015-07-28 15:10
Hi MT_dialog,

Hi MT_dialog,

I checked 1V8P on an oscilloscope during boot, using the DA1468x Pro DK connected to the LSM6DSL with our Proto2 pin assignments.

1) With the CS line disconnected, 1V8P is a steady 1.8V through boot (and also when I reset the Pro DK with switch K2).
2) With the CS line connected, 1V8P starts at 1.8V immediately after I release the Pro DK's reset switch (K2), then drops to about 1V within less than 200 ms. At that point, 1V8P immediately returns to 1.8V and then falls back toward 1.0V again, repeating this pattern indefinitely (presumably as the 1468x is in a crash and reboot cycle).

Thanks,
David

MT_dialog
Offline
Last seen: 1 week 10 hours ago
Staff
Joined: 2015-06-08 11:34
Hi david_33021,

Hi david_33021,

That means that for some reason the sensor that you have attached on the dev kit or on the proto board draws quite some power, more than the 1V8P can provide without voltage drops, so when the voltage drops the brown out detector kicks in and resets the board (1.65V is the typical value for the 1V8P). This sounds like more of short circuit. Now why exactly this occurs only when you have the CS on the P3_0 is quite strange,since there is no limitation or any kind of difference between those two pins, have you tried this using another sensor ? Or perhaps probe the P3_0, do you see the line toggling or driven at all from the 68x device, can you check if any toggling of the line is correlated with the fact that the 1V8P drops to 1V ? You can also measure the current on the supply 1V8P and also the the current on the CS and check if there is a current rush during boot.

Also something that would like to comment from the previous post, (i dont think that it has to do anything with your current issue but you should take care of that in order to avoid any future issues that you might have), as indicated on the datasheet pins P1_0, P1_5 and P1_7 might affect radio performance if toggling while RF activity. It is recommended to use then at low speed and not while radio is active. 

Thanks MT_dialog

david_33021
Offline
Last seen: 1 month 1 week ago
Joined: 2015-07-28 15:10
Hi MT_dialog,

Hi MT_dialog,

Thank you for your comments. We'll investigate as you suggest.

Also, thank you for pointing out that P1_7 is sensitive to high speed toggling. We had observed in the DA14680/681-01-KnownLimitations doc that we should avoid P1_0 and P1_5, but the KnownLimitations doc didn't mention P1_7 and we missed it in the datasheet.

David

david_33021
Offline
Last seen: 1 month 1 week ago
Joined: 2015-07-28 15:10
Hi MT_dialog,

Hi MT_dialog,

I burned the OTP using write_tcs to set our SPI clock pin, P4_1, as an output, initially logic high. With this change, our Proto2 setup on the Pro DK and our Proto2 PCBs (I've tested two so far) survive boot and operate normally. Yay!

Thanks,
David

MT_dialog
Offline
Last seen: 1 week 10 hours ago
Staff
Joined: 2015-06-08 11:34
Hi david_33021,

Hi david_33021,

Glad you found your way out, and thanks for sharing, but, just out of curiosity, have you figured out why exactly by setting the P4_1 high in the TCS operates with your setup ?

Thanks MT_dialog

david_33021
Offline
Last seen: 1 month 1 week ago
Joined: 2015-07-28 15:10
Hi MT_dialog,

Hi MT_dialog,

No, unfortunately, not yet. It seems very strange that we can reproduce the problem on the DA1468x pro kit. We bought another LSM6DSL breakout board to attach to the DA1468x pro kit and observed the same problem, so it's not a one-off problem with our particular LSM6DSL breakout. Every one of our PCBs in our Proto2 build has the problem, while all of the PCBs in our Proto1 build (same DA14680 and LSM6DSL and same software, just using different pins on the DA1468x) were just fine.

We're still investigating as we prepare for our (hopefully) final PCB build. I'll let you know if we discover anything.

Thanks,
David