nrf9160-dk spi clock configuration problem

[paul_tanner]

I made an own SPI device driver using the SDK's BM280 as a pattern

The result has a strange clock configuration (normally high - should be normally low)

Looking through other SPI drivers I do not see where this is coming from.

Is there an example of a *simple* spi driver that I can look at to see SPI clock configuration done right?

[paul_tanner]

I was using  SPI_TRANSFER_MSB | SPI_MODE_CPHA | SPI_MODE_CPOL

I have removed the last 2 of these 3 which seemed to improve the clock waveform.  But what does SPI_MODE_CPHA mean and where can one look up this sort of thing?

I found this in /ncs/zephyr/include/drivers/spi.h but can't say I understand it all.

SPI_LINES_DUAL sounds interesting as I will need 2 devices connected by SPI

Anyway, I simplified my main.c so it just calls sensor_sample_fetch

At this point I see cs going low and staying low.  No activity on the other 3 pins.

I restored SPI_MODE_CPHA | SPI_MODE_CPOL and this gets me back to where I started but the device I'm working with needs a normally low clock.

Finally, I took out all the config bits.  This then produces something that looks correct.

Additionally, the CS pin does not change.  It should go low when an SPI transfer takes place.

Excerpt from board overlay

&spi2 {
 compatible = "nordic,nrf-spim";
 status = "okay";
 sck-pin = <19>;
 mosi-pin = <18>;
 miso-pin = <17>;
 cs-gpios = <&gpio0 16 GPIO_ACTIVE_LOW>;
 
 buggyair@16 {
   compatible = "buggyair,ss3";
   status = "okay";
   reg = <0x00>;
   spi-max-frequency = <4000000>;
   label = "BUGGYAIR";
 };
};

device constructor

/*
#define SS3 DT_INST(0, buggyair_ss3)
#if DT_NODE_HAS_STATUS( SS3, okay)
#define DEV_LABEL DT_LABEL(SS3)
#else
#error Your devicetree has no enabled nodes with compatible "buggyair,ss3"
#define DEV_LABEL "<none>"
#endif
*/

#define DEV_LABEL "SPI_2"
const struct device *source = device_get_binding(DEV_LABEL);

The original device constructor caused an immediate crash. Replacing this with "SPI_2"
makes it run but, understandably nothing happens on PO.16

Any advice appreciated.