xG24-DK2601B // Getting gecko spi driver to instanciate

[Dermiste]

Hi all,

I am working on the efr32xg24_dk2601b, I am trying to get the ICM-20689 to work. To achieve that, I edited an overlay and linked the provided driver zephyr\drivers\spi\spi_gecko.c.

Here is the overlay which I got from searching the code base, the provided values are probably not right BUT I assume I can at least get a proper compile:

/ {
	soc {
		spi0: eusart@5b010000 {
			reg = <0x5b010000 0x400>;
			interrupts = < 0x9 0x0 >, < 0xa 0x0 >;
			interrupt-names = "rx", "tx";
			peripheral-id = < 1 >;

			compatible = "silabs,gecko-spi-usart";
			#address-cells = <1>;
			#size-cells = <0>;

			location-rx = <GECKO_LOCATION(11) GECKO_PORT_C GECKO_PIN(3)>;
			location-tx = <GECKO_LOCATION(11) GECKO_PORT_C GECKO_PIN(2)>;
			location-clk = <GECKO_LOCATION(11) GECKO_PORT_C GECKO_PIN(1)>;

			cs-gpios = <&gpioa 7 GPIO_ACTIVE_LOW>;

			status = "okay";
		};
	};
};

But can't get that to compile, I get an error during instanciation which leads to:
.

And the beginning of the stack call:

Problem is, on this board there is only 1 USART and 2 EUSART, so any refering to USART1 does not exist ...

@fkokosinski & @lpawelcz, it seems you worked on that file, do you have any idea what might cause that?

Thanks for any tips ! Or any overlay lying around you could send over :)

[fkokosinski]

Hi @Dermiste, thanks for asking.

Unfortunately, the driver in question does not support EUSART, as it relies on the USART API that Emlib exposes, so the only option that there is in Zephyr right now for using SPI with this SoC is to reconfigure the USART node to act as a SPI controller. This of course also means that UART would be disabled and not available for the user, and that’s why it wasn’t added/configured that way in the SoC devicetree file.

I’m not sure why you’re getting the error that you’ve listed in your post. I haven’t investigated this problem in depth, but it looks like perhaps something changed in the HAL (maybe we had a custom fixup for this error that got lost in one of the GSDK bumps?). The snippet below seems to fix the issue for me:

diff --git a/drivers/spi/spi_gecko.c b/drivers/spi/spi_gecko.c
index 3f771b6740..020159df28 100644
--- a/drivers/spi/spi_gecko.c
+++ b/drivers/spi/spi_gecko.c
@@ -33,10 +33,10 @@ LOG_MODULE_REGISTER(spi_gecko);
 #define CLOCK_USART(id) _CONCAT(cmuClock_USART, id)
 #define GET_GECKO_USART_CLOCK(n) CLOCK_USART(DT_INST_PROP(n, peripheral_id))
 #else
-#if (USART_COUNT <= 1)
+#if (USART_COUNT == 1)
 #define CLOCK_USART(ref)       (((ref) == USART0) ? cmuClock_USART0 \
                               : -1)
-#elif (USART_COUNT <= 2)
+#elif (USART_COUNT == 2)
 #define CLOCK_USART(ref)       (((ref) == USART0) ? cmuClock_USART0 \
                               : ((ref) == USART1) ? cmuClock_USART1 \
                               : -1)

Also, please note that the location-* properties are considered deprecated in Zephyr, and you should use the Pinctrl API instead. You can check these two files to see how pinmuxing should be done instead (on the example of BG22 support):

• https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/arm/silabs/efr32bg2x-pinctrl.dtsi#L11-L18
• https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/efr32_thunderboard/thunderboard.dtsi#L75-L95

[Dermiste]

HI @fkokosinski,

Thanks for your answer, that explains why I couldn't get the driver to work.

Since I found in the HAL a em_eusart.h/c I'm going to copy and adapt the current driver to make it work with that layer. So far I managed to have a "nearly working component", chip select is operationnal and the only missing thing is a working clock + MOSI.
Although no signals are to be seen on the scope I'm confident I operate the right pins since I'm at least able to change their idle state

Here is my DTS overlay:

&pinctrl {
		/* configuration for usart0 device, operating as SPI */
		eusart0_default: eusart0_default {
			group1 {
				psels = <GECKO_PSEL(SPI_SCK, C, 1)>,
					<GECKO_PSEL(SPI_MOSI, C, 3)>,
					<GECKO_PSEL(SPI_MISO, C, 2)>;
			};
		};
};

Derived from:

Lastly, I found this sample in em_eusart.h:

///  EUSART Sync SPI Transaction example:
///  @code{.c}
///  {
///    EUSART_SpiInit_TypeDef init_master = EUSART_SPI_MASTER_INIT_DEFAULT_HF;
///
///    // Configure the clocks.
///    CMU_ClockSelectSet(cmuClock_EM01GRPCCLK, cmuSelect_HFRCODPLL);
///    CMU_ClockEnable(cmuClock_EUSART1, true);
///    CMU_ClockEnable(cmuClock_GPIO, true);
///
///    //Configure the SPI ports
///    GPIO_PinModeSet(sclk_port, sclk_pin, gpioModePushPull, 0);
///    GPIO_PinModeSet(mosi_port, mosi_pin, gpioModePushPull, 0);
///    GPIO_PinModeSet(mosi_port, miso_pin, gpioModeInput, 0);
///
///    // Connect EUSART to ports
///    GPIO->EUSARTROUTE[EUSART_NUM(EUSART1)].TXROUTE = (mosi_port << _GPIO_EUSART_TXROUTE_PORT_SHIFT)
///                                                     | (mosi_pin << _GPIO_EUSART_TXROUTE_PIN_SHIFT);
///    GPIO->EUSARTROUTE[EUSART_NUM(EUSART1)].RXROUTE = (miso_port << _GPIO_EUSART_RXROUTE_PORT_SHIFT)
///                                                     | (miso_pin << _GPIO_EUSART_RXROUTE_PIN_SHIFT);
///    GPIO->EUSARTROUTE[EUSART_NUM(EUSART1)].SCLKROUTE = (sclk_port << _GPIO_EUSART_SCLKROUTE_PORT_SHIFT)
///                                                     | (sclk_pin << _GPIO_EUSART_SCLKROUTE_PIN_SHIFT);
///    GPIO->EUSARTROUTE[EUSART_NUM(EUSART1)].ROUTEEN = GPIO_EUSART_ROUTEEN_TXPEN | GPIO_EUSART_ROUTEEN_SCLKPEN;
///
///    // Initialize the EUSART
///    EUSART_SpiInit(EUSART1, &init_master);
///    EUSART_Spi_TxRx(EUSART1, data);

Do you reckon it's enough to get SPI working on EUSART0 ? Correct me if I'm wrong but this should also work straight up from a main.c right? those are just calls to a HAL that should be operationnal by itself without any zephyr wrapping.

Clock wise, are those three lines above enough to configure the clock for that component?

Any tips or bits of code much appreciated :)

Thanks in advance

[Dermiste]

Update, it turns out that using EUSART0 does not work but using EUSART1 does, I can successfully see the data I send over on MOSI.
I am trying to read WHOAMI register but I see on the scope a huge delay between the first and the second words, I don't think a sensor is supposed to wait that long in between words and that's why I get no answer.
Using simplicity studio I got a working example where WHOAMI can be read, but it's done using DMA so 0 delay between words, but it proves at least the sensor is operationnal.

The current spi_gecko.c driver is based on USART in SPI mode and is published online, which means there is no performance issue with that part, doing the same thing with EUSART should not be an issue right? Any red flag to report before I dig more?

More to come, maybe someone will be interested in a pull request after a starting has been properly initiated.

[Dermiste]

Update, the SPI delay between words is no issue but it turned out that the sensor is not properly powered.

There is this component in the DTS which is meant to enable the sensor:

I thought it was working but I managed to get an answer from the slave only when I directly enabled the pin inside the driver using:
GPIO_PinModeSet(2, 9, gpioModePushPull, 1);

The no power state can also be seen on other sensor at startup where I2C device cannot read their slave address.

@fkokosinski any idea if that way of powering up the sensors was working fine at some point? In any case fixing it is definitely of interest for anyone who wants to test communication with all sensors.

[fkokosinski]

Hi, I can confirm that this node was meant to enable the on-board sensor switches (U101A and U102A on the schematic). I did a quick test with the samples/subsys/shell/shell_module sample:

west build -p -b efr32xg24_dk2601b samples/subsys/shell/shell_module -- -DCONFIG_I2C=y -DCONFIG_I2C_SHELL=y
west flash

And in the Zephyr shell:

uart:~$ i2c scan i2c@5b000000
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:             -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- 29 -- -- -- -- -- --
30: 30 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- 77
4 devices found on i2c@5b000000

Which is the correct result. Commenting out the sensor_enable node yields the following:

uart:~$ i2c scan i2c@5b000000
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:             -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
0 devices found on i2c@5b000000

Which was expected. Meaning the sensor_enable node seems to be working correctly, at least in my case.

Is there a possibility that you could create a WIP PR with your progress so far to Zephyr? To be frank, it's difficult to figure things out from code screenshots only, without the possibility to play with the code a bit :)

[Dermiste]

Yes I confirm it did actually work, although I had to change the regulator init priority to let enough startup time for certain I2C sensors, otherwise the slave address could not be read consistently during app startup. Don't know if this is the right way to go thought.

Regarding the WIP PR, is it okay if I create it without being sure of completing it? I had time in the past weeks but it's very probable that I won't have more to spare in the coming days/weeks.

So far I created a spi-gecko-eusart driver along with a icm-20689 driver, working fine as to get at least WHO_AM_I + gyro acc readings.

[fkokosinski]

Regarding the WIP PR, is it okay if I create it without being sure of completing it?

Yup, it's totally fine

[Dermiste]

Ok will do asap then, awaiting one first PR to be pulled so I can fork another one

[adri1mart1]

Hello,

Side note as you wrote "Update, it turns out that using EUSART0 does not work but using EUSART1 does".
Looking from your initial code, this is maybe normal due to the following differences:

Based on the reference manual link.

You have defined initially:

spi0: eusart@5b010000 {
    reg = <0x5b010000 0x400>;

But the address range for the eusart0 is 0x4B010000 - 0x4B013FFF (See ref manual p. 46). So you are missing a zero. It should be reg = <0x5b010000 0x4000>.

Also your interrupts:

interrupts = < 0x9 0x0 >, < 0xa 0x0 >;
interrupt-names = "rx", "tx";

It should be interrupts = <11 0>, <12 0>; (See ref manual p.38).

Peripheral-id should be set to 0 (match with eusart0).

There may be other ones but that's what I've spotted so far.

Regards,
Adrien M.