nRF9160 SPI and spi_cs_control

RE: nRF9160 SPI and spi_cs_control

Øyvind — Thu, 17 Dec 2020 11:26:25 GMT

Hello Dirk,

I'm glad that you have a work around for the moment. It seems that a complete driver must be in place in order for you to implement my previous suggestion.

Kind regards,
Øyvind

RE: nRF9160 SPI and spi_cs_control

dhandzic — Fri, 11 Dec 2020 14:37:34 GMT

Hi Öyvind,

I have added the cs-gpios to my devicetree .dts file as you can see but I dont have written a complete driver for the MC33879 and I am not sure how to add a child node without being able to refer to a driver module.like in the Thingy example "compatible=adi,adx1362".

Never mind it is working with calling gpio_pin_set as I do now too.

Have a nice Friday!
Dirk

RE: nRF9160 SPI and spi_cs_control

Øyvind — Fri, 11 Dec 2020 13:20:13 GMT

Hello,

I've discussed the topic with our R&D team.

You need to add the SPI devices as a childe node to your SPI instance in the .dts file. What SPI device are you using? Have a look at the common dts file for e.g. Thingy:91 on how to add a child node. Based on this information, you can add the SPI CS pin.

Then using DT_SPI_DEV_CS_GPIOS_FLAGS() you use the child node from above. For example from the Thingy:91 you should be able to use DT_SPI_DEV_CS_GPIOS_FLAGS(DT_LABEL(adxl362)).

I have unfortunately not been able to test this, as my setup is working with me on this Friday.

-Øyvind

RE: nRF9160 SPI and spi_cs_control

dhandzic — Thu, 10 Dec 2020 09:12:48 GMT

Hi Öyvind,

great you could reproduce the issue. I have tried to follow all the documentation regarding the device tree for custom boards.

Best regards

Dirk

RE: nRF9160 SPI and spi_cs_control

Øyvind — Thu, 10 Dec 2020 08:44:02 GMT

Hi Dirk,

I can confirm the issue using the project provided in ticket #260408.

The issue seems to be related to device tree configurations, please see DeviceTree HOWTOs for more information. Unfortunately, I have not work with Devicetree configurations and will need to confer with a colleague in R&D.

More information on this topic can also be found in "Devicetree main header" (zephyr\include\devicetree.h) and the "SPI Devicetree macro public API header file" (zephyr\include\devicetree\spi.h).

Kind regards,
Øyvind

RE: nRF9160 SPI and spi_cs_control

dhandzic — Mon, 07 Dec 2020 14:38:21 GMT

Hi Öyvind,

I am configuring spi in the board files. Carl Rchard Steen Fosse has received both device tree and project files in a private ticket. Case ID: 260408

In the code I have removed the cs part and toggle CS directly in my code which works for the MC33879 I need to control. If you just change it in qlocx_digio.c you will get the error back. Carl Richard Steen Fosse has one of our boards, in case you need a board.

Best regards

Dirk

RE: nRF9160 SPI and spi_cs_control

Øyvind — Mon, 07 Dec 2020 14:14:43 GMT

Hello,

Are you configuring anything in you application? Or is it just in your board files?

I'm not able to reproduce the error with the board files alone.

-Øyvind

RE: nRF9160 SPI and spi_cs_control

dhandzic — Fri, 04 Dec 2020 13:11:19 GMT

Hi Öyvind,

devzone.nordicsemi.com/.../Q3IoT_5F00_201204.zip

Even after adding the cs definitions to our board_common.dts I get similar errors. I attach our board definition files.

Best regards

Dirk

RE: nRF9160 SPI and spi_cs_control

Øyvind — Fri, 04 Dec 2020 11:39:25 GMT

Hi Dirk,

From the top of output log you have provided, it states:
devicetree and spi_context CS levels are not equal

Have you configured SPI in your devicetree?

We have a simple (a little outdated) sample on SPI here

The gpio_dt_flags are GPIO devicetree flags:

/**
 * @brief SPI Chip Select control structure
 *
 * This can be used to control a CS line via a GPIO line, instead of
 * using the controller inner CS logic.
 *
 * @param gpio_dev is a valid pointer to an actual GPIO device. A NULL pointer
 *        can be provided to full inhibit CS control if necessary.
 * @param gpio_pin is a number representing the gpio PIN that will be used
 *    to act as a CS line
 * @param delay is a delay in microseconds to wait before starting the
 *    transmission and before releasing the CS line
 * @param gpio_dt_flags is the devicetree flags corresponding to how the CS
 *    line should be driven. GPIO_ACTIVE_LOW/GPIO_ACTIVE_HIGH should be
 *    equivalent to SPI_CS_ACTIVE_HIGH/SPI_CS_ACTIVE_LOW options in struct
 *    spi_config.
 */
struct spi_cs_control {
	const struct device	*gpio_dev;
	uint32_t		delay;
	gpio_pin_t		gpio_pin;
	gpio_dt_flags_t		gpio_dt_flags;
};

There are several examples of the usage in NCS, i.e.

More information on Device Tree can be found here.

E.g. from nrf\boards\arm\thingy91_nrf9160\thingy91_nrf9160_common.dts you can see how the Thingy:91 has configured SPI3 CS pin.

Kind regards,
Øyvind