SPIM/UARTE register conflict with hal_nordic

We are using the Nordic fork of Zephyr on nRF5340.

Looking at the serial interface peripherals (SPI/I2C/UART), we understand that these have shared resources and only one peripheral with a given ID can be active.

However there is a conflict with the register definitions and the reset/default values.

The register at offset 0x56C is used by two peripherals:
* by SPIM as PSELDCX with a reset value of 0xFFFFFFFF
* by UARTE as CONFIG with a reset value of 0x00000000

While investigating with a debugger, we see that the actual reset value is 0x00000000.

It seems that the driver in nrfx/drivers/src/nrfx_spim.c is not aware of this.

The function nrfx_spim_init will not modify the PSELDCX register if p_config->dcx_pin == NRFX_SPIM_PIN_NOT_USED.

Also, nrfx_spim_uninit will wrongly set pin 0 to default GPIO values, because it thinks that DCX is configured to pin 0.

Is this a bug in the hal_nordic code or are we doing something wrong?

As a workaround, we will try setting the register at offset 0x56C to 0xFFFFFFFF, before initializing the hal_nordic driver.

Parents
  • Hi,

    DCX functionality is only supported in SPIM4 (32 MHz High-speed instance), see "Configuration" column next to each instance in Registers. SPIM4 does not share any resources with UARTE, as there is no UARTE4 instance, see Peripheral instantiation.

    You should not enable DCX for other instances of SPIM when initializing the SPIM driver.

    Best regards,
    Jørgen

  • Yes, you should make sure to set p_config->dcx_pin == NRFX_SPIM_PIN_NOT_USED for all other instances than SPIM4, then the init function should not change this and make issues for the UARTE instances using this register.

    The uninit-function seems to contain a bug, and is something we should handle better. Previous chips have not had these issues, as nRF52 series ICs had separate base addresses for UART(E) instances (not shared with SPI/TWI), and nRF91 did not include the 32MHz high-speed SPI instance, so there was no DCX support at all. I will report this issue to our developers to get it fixed in future releases of NRFX.

Reply
  • Yes, you should make sure to set p_config->dcx_pin == NRFX_SPIM_PIN_NOT_USED for all other instances than SPIM4, then the init function should not change this and make issues for the UARTE instances using this register.

    The uninit-function seems to contain a bug, and is something we should handle better. Previous chips have not had these issues, as nRF52 series ICs had separate base addresses for UART(E) instances (not shared with SPI/TWI), and nRF91 did not include the 32MHz high-speed SPI instance, so there was no DCX support at all. I will report this issue to our developers to get it fixed in future releases of NRFX.

Children
No Data
Related