SPI Peripheral Power Consumption much higher than nrf5 SDK

RE: SPI Peripheral Power Consumption much higher than nrf5 SDK

S_C — Sun, 04 Jun 2023 07:52:49 GMT

Hi,

we are not setting the SPI to high we just using spi_transceive with the device that configure to spi1

Thanks

RE: SPI Peripheral Power Consumption much higher than nrf5 SDK

Kenneth — Thu, 01 Jun 2023 09:56:39 GMT

I suggest connect a logic analyzer to find what has changed: look at level of csn pins and spi pins.

Kenneth

RE: SPI Peripheral Power Consumption much higher than nrf5 SDK

S_C — Thu, 01 Jun 2023 07:43:07 GMT

No, I just control spi1 , spi0 configure in the overlay as you can see in the overlay file above.

I control spi1 using

peripherals_1.c file
const struct device *peripherals_1 =  DEVICE_DT_GET(DT_NODELABEL(spi1));

peripherals_2.c file
const struct device *peripherals_2 =  DEVICE_DT_GET(DT_NODELABEL(spi1));

main.c

get_peripherals_1_device....
get_peripherals_2_devie....

Thanks!

RE: SPI Peripheral Power Consumption much higher than nrf5 SDK

Kenneth — Thu, 01 Jun 2023 07:24:35 GMT

[quote user="S_C"]Our only question is that we cannot remove the unused spi0 (by disabling in overlay) or remove it's pinctrl without harming the "spi0" peripheral functionality, even though it is now pointing to spi1. Do you happen to know why this is?[/quote]

Are you controlling both csn pins (e.g. set them high at startup)?

Kenneth

RE: SPI Peripheral Power Consumption much higher than nrf5 SDK

S_C — Wed, 31 May 2023 15:12:30 GMT

Hi Kenneth,
We were able to use your suggestion on spi1 without having to turn off the CS pins manually - which enabled us to use the correct mode (CPOL | CPHA) on the second SPI peripheral which we were unable to do before. Thanks!

Our only question is that we cannot remove the unused spi0 (by disabling in overlay) or remove it's pinctrl without harming the "spi0" peripheral functionality, even though it is now pointing to spi1. Do you happen to know why this is?

Thanks!
Shahar

RE: SPI Peripheral Power Consumption much higher than nrf5 SDK

Kenneth — Wed, 31 May 2023 13:19:32 GMT

[quote user="S_C"]from my understanding there is no problem to share the SPI pins except Chip/Slave Select
if you manage to not use both of them at the same time. [/quote]

True, but from your code it looks like you are using both spi0 and spi1, and they use the pins? This will be problematic, since you are using two hardware peripherals with the same pins.

If you only have different spi chip select pin, then why not just do something like:

csn_1 = 0;
spi_transceive(spi0,...)
csn_1= 1;

csn_2 = 0;
spi_transceive(spi0,...)
csn_2= 1;

Kenneth

RE: SPI Peripheral Power Consumption much higher than nrf5 SDK

S_C — Wed, 31 May 2023 12:53:15 GMT

Hi ,

from my understanding there is no problem to share the SPI pins except Chip/Slave Select
if you manage to not use both of them at the same time.

After I use CONFIG_PM_DEVICE=y, both of my peripherals are not working and the RTT is not working as well, there is an example with similar case in zephyr?

Thanks!

RE: SPI Peripheral Power Consumption much higher than nrf5 SDK

Kenneth — Wed, 31 May 2023 11:59:30 GMT

Hello,

I am not entirely sure I understand how you solved this in the old nRF5 SDK and how you are planning to do this on the new nRF Connect SDK, and what the problem may be. Dynamic switching / sharing of pins is not straight forward, you need to ensure that two peripherals trying to use the same pin(s) are not enabled at the same time at any given time. In your case you might also want to measure the pins in question using a logic analyzer to ensure that the pin level and mode is the same between old and new SDK.

Today it can be possible to use the device power management to achieve pin sharing. If you use CONFIG_PM_DEVICE=y, then you have the option to call for instance pm_device_action_run(peripheral_dev, PM_DEVICE_ACTION_RESUME); and pm_device_action_run(peripheral_dev, PM_DEVICE_ACTION_SUSPEND); to control which configuration is used. It should be possible to switch between usage that way, as long as only one peripheral_dev is active ("RESUME") at any given time.

Best regards,
Kenneth