Morse Micro MM6108 Integration on i.MX8MP (SPI Response Issue)

[arti.rajput]

Hi,

We are trying to integrate the Morse Micro MM6108 chip on i.MX8MP hardware using the ECSPI2 interface. Below is my device tree configuration:

&ecspi2 {
#address-cells = <1>;
#size-cells = <0>;
fsl,spi-num-chipselects = <1>;
pinctrl-names = “default”;
pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>;
cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
status = “okay”;

morse_wifi: morse-micro@0 {
	compatible = "morse,mm610x-spi";
	reg = <0>;
	pinctrl-names = "default";
	reset-gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
	interrupt-parent = <&gpio5>;
	interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
	spi-max-frequency = <1000000>;
	status = "okay";
};

};

With this setup, I am observing the following kernel logs:

[ 17.576937] Morse Micro Dot11ah driver registration. Version 0-rel_1_14_1_2024_Dec_05
[ 17.622720] morse micro driver registration. Version 0-rel_1_14_1_2024_Dec_05
[ 17.623376] morse_spi spi1.0: morse_spi_find_response: SPI response error
[ 17.623382] morse_spi spi1.0: morse_spi_probe: SD_IO_RESET
[ 17.623713] morse_spi spi1.0: morse_spi_find_response: SPI response error
[ 17.624048] morse_spi spi1.0: morse_spi_find_response: SPI response missing
[ 17.624053] morse_spi spi1.0: morse_spi_probe: SD_IO_RESET
[ 17.624440] morse_spi spi1.0: morse_spi_find_response: SPI response missing
[ 17.624779] morse_spi spi1.0: morse_spi_find_response: SPI response error
[ 17.624785] morse_spi spi1.0: morse_spi_probe: SD_IO_RESET
[ 17.624971] morse_spi spi1.0: morse_spi_find_response: SPI response missing
[ 17.624977] morse_spi spi1.0: morse_spi_probe: failed to init SPI with CMD63 (ret:-71)
[ 17.624997] morse_spi_probe failed. The driver has not been loaded!
[ 17.625001] morse_spi: probe of spi1.0 failed with error -71

We have also measured the SPI signals using a logic analyzer. It appears that the MM6108 is responding, but the returned data is random:
0xFF, 0x9F, 0xBF

Could you please advise:

1. Are there any specific hardware requirements (e.g., SPI pull-ups, clock phase/polarity settings) that we should follow for the MM6108?
2. Is there any issue in our device tree configuration that could cause the SPI response errors?

Any additional debugging steps you recommend?

Looking forward to your guidance.

Thanks

[ajudge]

Hi @arti.rajput

It looks like the chip is failing to respond at all to the host. CMD63 is the first command sent by our driver.

For your device tree configuration, we use a custom property - spi-irq-gpios to configure the SPI interrupt GPIO. Please add this to the morse_wifi node.

Regarding pull-ups, it is important that the SD_D2 pin of the Morse Micro chip has a pull up. For initial development, you may want to insert pullups on all data lines. The clock line shouldn’t need a pull-up, but it can be helpful to leave a footprint there - just in case.

Can you share the logic analyser capture you have on hand?

[arti.rajput]

Hi @ajudge ,

Thanks for your response.

Here is my updated device tree node with the spi-irq-gpios property added as suggested:

&ecspi2 {
#address-cells = <1>;
#size-cells = <0>;
fsl,spi-num-chipselects = <1>;
pinctrl-names = “default”;
pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>;
cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
status = “okay”;

morse_wifi: morse-micro@0 {
	compatible = "morse,mm610x-spi";
	reg = <0>;
	reset-gpios = <&gpio5 8 0>;
	power-gpios = <&gpio3 21 0>,
	              <&gpio3 23 0>;
	spi-irq-gpios = <&gpio5 9 0>;
	spi-max-frequency = <1000000>;
	status = "okay";
};

};

Attached below is a snapshot of the logic analyzer capture.

We have applied all the patches from morsemicro_kernel_patches_rel_1_14_1_2024_Dec_05.

Regarding the pull-ups, could you confirm if they are mandatory? Specifically, is the pull-up on SD_D2 essential, or should we consider adding pull-ups on all data lines for initial testing?

Additionally, apart from the above patches, can you confirm if any other software changes are required to ensure proper initialization?

Thanks,

[ajudge]

Aside from the kernel patches, there shouldn’t be any other software changes you need to make. I shared our Linux porting guide application note in this thread if it is of benefit to you: Raspberry Pi Zero 2W WiFi HaLow Module (MM6108-MF08651-US) Integration

The pull up on SD_D2 is essential. Other pull ups on data lines are often not necessary, so long as the host is actively driving the lines (configured “push-pull”). I would recommend putting pull up resistors on these data lines during initial development, and remove them if you need to tune aggressively for power save.

The pull-up on the clock line should not be needed. However, I have seen one instance where it was. Possibly a host misbehaving - we haven’t had a chance to do a deeper analysis on the device. If you’re designing a board, I would recommend putting a footprint for a pull up on that line, but leave it unpopulated.

Please share the actual logic analyser files if you can. It allows me to more closely examine the trace.

[arti.rajput]

Hi @ajudge ,
Please find the attached capture files.
Session 0.sal (4.5 KB)

We have created our own PCB by taking the below document as reference:

As you can see there is no pull up connected to the data lines

While for SDIO, there are pull-ups:

Thanks

[ajudge]

Yes, for the SPI lines that reference is correct. It has the SD_D2 pull-up which is essential, and you will likely find that any other pull up on the data lines is unnecessary.
However, as mentioned, I think it is a good idea to have footprints present on the other lines during initial hardware bring up in case you require a pull up.

There is a small gap in this reference design though for designs using Linux. Our Linux driver doesn’t “drive” the RESET line high, it only drives it low or puts it into a Hi-Z state. So you will want to be configuring a pull up on the RESET line.
You should be able to do this in device tree by adjusting the pad_setting for the given GPIO, but otherwise an external pullup will work.

I’ll raise this gap with the hardware team.

I’ll take a closer look at the LA captures shortly. Thanks for sending them through!

[ajudge]

Hi @arti.rajput

Something I forgot to mention earlier. If you have access to the MM6108 datasheet, take note of footnote 4 of Table 2. The RESET_N and WAKE pins are in the VBAT domain. So RESET_N must be pulled up to 3V3 even if you are using 1V8 logic.

[arti.rajput]

Hi @ajudge,
Yes the reset pin is pull up.
Do you have any update on the logic analyser capture?

[ajudge]

Please assess the signal integrity of your clock line (or, your logic analyzer settings). From this part of the capture. The clock is heavily disturbed - there are oscillations that do not meet the expected 1us you would expect for 1 MHz.

There are also what look like unexpected oscillations on the enable line. Is the logic level for the analyzer configured for the right VH/VL? Is there something else in the signal driving, or otherwise disturbing this line?
It could be that the lines are configured for open drain. Make sure they’re configured as push-pull or have pull ups.

I note that earlier in the trace the enable line asserted during an initial clock transition.