nRF5340 + 7002EK: rpu_validate_comms() check fails for SPI frequency of 16 MHz

[Ladivin]

Hello DevZone,

I have an nRF5340 devkit along with an nRF7002EK, and I'm looking to upgrade from SDK version 2.6.1 to 2.6.4. However, I'm facing an issue. In version 2.6.2, a new check was introduced in nrf\drivers\wifi\nrf700x\src\qspi\src\rpu_hw_if.c, specifically the rpu_validate_comms() function added to rpu_enable(). This check fails for me when I use an SPI frequency other than 8 MHz for communication with the nRF7002-EK.

To change the frequency I use the following property of nrf700x node in my device tree overlay: spi-max-frequency = <DT_FREQ_M(16)>

Is this intended behavior, or could it be a bug?

Also, I'm attaching a screenshot of the above mentioned failure:

Many thanks!

Ladivin

[Håkon Alseth]

Hi,

 

I see this issue on v2.6.x and v2.7.0, but it seems to be fixed on v2.8.0 and newer.

Do you see similar behavior as me?

 

Kind regards,

Håkon

[Ladivin]

Hi Håkon!

Thanks for your response. Actually, I can see this issue on 2.6.2, 2.6.3 and 2.6.4, but 2.7.0 works fine for me, because if I look into its nrf\drivers\wifi\nrf700x\src\qspi\src\rpu_hw_if.c the check that is failing is not present there. 

This leads me to a question - why are some of the Wi-Fi fixes backported to 2.6.X and not to 2.7.X? Is 2.6.X some kind of a long term support version? 

So far, I was not able to try out 2.8.0 or above, because our code is quite complex and I haven't succeeded in building it for 2.8.0. 

If I understand correctly, in general it is fine to have a nRF7002 on SPI (SPI4 in our case) with frequency of 16 MHz and there is no requirement to keep it on 8 MHz, correct? 

BTW what happens if I connect two devices with different frequency to the same SPI? Will the frequency change depending on which device I'm talking to, or will the lower frequency of these two be used? 

Thanks!

Ladivin 

[Håkon Alseth]

Hi Ladivin,

 

The function rpu_validate_comms was added to ncs v2.8.0 with this commit:

https://github.com/nrfconnect/sdk-zephyr/commit/62c3b41d8811f9c08909eb516373c270dc195a59

And also backported to v2.6-branch.

Ladivin said:

If I understand correctly, in general it is fine to have a nRF7002 on SPI (SPI4 in our case) with frequency of 16 MHz and there is no requirement to keep it on 8 MHz, correct? 

Just for verification purposes: I have created a jira ticket internally to look into if this is a requirement. I will update you within 3 business days with more information on this topic.

Ladivin said:

BTW what happens if I connect two devices with different frequency to the same SPI? Will the frequency change depending on which device I'm talking to, or will the lower frequency of these two be used? 

SPI frequency can be switched on-the-fly with the driver. Be sure to change the "spi-max-frequency" for the subsequent sensor.

And also note: Adding several sensors on the same SPI interface will add capacitance, so in certain scenarios (depending on overall track-length and the added load for each sensor), you may have to reduce the max frequency.

 

Kind regards,

Håkon

[Ladivin]

Hi Håkon,

many thanks for your response. 

Håkon Alseth said:

Just for verification purposes: I have created a jira ticket internally to look into if this is a requirement. I will update you within 3 business days with more information on this topic.

Perfect! Thanks!

Best Regards,

Ladivin

[Håkon Alseth]

Hi Ladivin,

 

I can confirm that there is a requirement for lowering the SPI clock speed for nRF700x RPU wakeup. This is implemented with this PR for SPI:

https://github.com/zephyrproject-rtos/zephyr/pull/87706

 

Could you try this and see if that fixes the issue on your end?

 

Kind regards,

Håkon

[Ladivin]

Hello Håkon,

Again, thanks for your answer.

This is very interesting. Actually, we've been using the 7002 on 16 MHz for some time now on SDK 2.9 and it seem to work fine even without the PR you shared. But I guess that we might have been just lucky and the RPU wakeup is not reliable on 16 MHz without that PR?

Also, previously, you mentioned, that each device sharing an SPI bus can have its own frequency. What confuses me is, that when I go to Nordic's device three visual editor, I can see the following hint on SPI's max frequency:

If I understand it correctly, this implies that the maximal SPI frequency the frequency of the slowest device? 

Thanks,

Ladivin

[Håkon Alseth]

Hi Ladivin,

Ladivin said:

But I guess that we might have been just lucky and the RPU wakeup is not reliable on 16 MHz without that PR?

There has been work done to improve robustness, by adding retries and "RPU lockup detection" functionality that was introduced under-the-hood for the wifi ready library, as shown in the STA sample:

https://github.com/nrfconnect/sdk-nrf/blob/main/samples/wifi/sta/src/main.c#L59

This could explain why it works more stable in newer versions.

Ladivin said:

Also, previously, you mentioned, that each device sharing an SPI bus can have its own frequency. What confuses me is, that when I go to Nordic's device three visual editor, I can see the following hint on SPI's max frequency:

That sentence is indeed a bit misleading, I will bring this up with the vscode plugin team. The maximum frequency of the slave is one parameter, and the maximum frequency of the master is another. The masters maximum frequency will always be set as the ceiling, then the slave max-freq will be considered next. However, even if a SPIM device is capable of higher frequencies does not automatically mean that it will work. Drive strength and timing parameters must in general not be violated.

 

Instances in zephyr can switch the frequency based on each individual sensors max frequency set in device tree.

What will need to be taken into account is that the overall capacitance and impedance will be a direct component of how many devices are connected to a physical SPI bus. Even if all other sensors are off, there will still be a bit of capacitance in each pad and PCB trace for instance.

 

Kind regards,

Håkon