Bus Fault in DMIC Driver on NRF9160 After Upgrading to SDK Version 2.5.0

[sensorbee-dev]

I've recently encountered an issue with the DMIC driver on the NRF9160 after updating to SDK version 2.5.0. Specifically, a bus fault arises during the initialization phase of Zephyr.

Some observations and details:

• The BusFault Address Register (BFAR) indicates that the fault was triggered by address 0x40006540 [PDM->CLK].
• The previous SDK version I was using was 2.4.2, and I didn't experience this issue.
• I haven't made any modifications to the DMIC configuration or altered anything within the device tree.
• Due to the early occurrence of the fault during the boot-up process, I've been unable to retrieve any logs.
• I have also tried to look for any changes in the driver that could be causing this issue, but there does not seem to have been any significant changes recently.

Has anyone else faced a similar issue or have suggestions on how to resolve it?

This is the DTS configuration that I am currenly using:

&pinctrl {
    pdm0_default_alt: pdm0_default_alt {
        group1 {
            psels = <NRF_PSEL(PDM_CLK, 0, 22)>,
                <NRF_PSEL(PDM_DIN, 0, 21)>;
        };
    };
};

dmic_dev: &pdm0 {
    status = "okay";
    pinctrl-0 = <&pdm0_default_alt>;
    pinctrl-names = "default";
    clock-source = "PCLK32M_HFXO";
};

[Raoul]

Hi, and sorry for the late reply.

• The BusFault Address Register (BFAR) indicates that the fault was triggered by address 0x40006540 [PDM->CLK].
• The previous SDK version I was using was 2.4.2, and I didn't experience this issue.
• I haven't made any modifications to the DMIC configuration or altered anything within the device tree.
• Due to the early occurrence of the fault during the boot-up process, I've been unable to retrieve any logs.
• I have also tried to look for any changes in the driver that could be causing this issue, but there does not seem to have been any significant changes recently.

Thanks for your clear description!

Has anyone else faced a similar issue or have suggestions on how to resolve it?

No, I can't find any reference to this either internally or on DevZone. But v2.5.0 has not been out for long.

I also don't see any changed to DMIC drivers mentioned in the release notes.

So far I haven't figured out what could be causing this, but I'll let you know if I find anything. Keep me updated if you happen to fix it!

By the way, which board are you using? Are you able to run your application on a DK, on v2.4.2 and v2.5.0? Or have you tried running the DMIC sample in v2.5.0?

Best regards,

Raoul

[sensorbee-dev]

Hi Raoul,

Thank you for looking into this. I appreciate your efforts. Here's an update on the situation after following your suggestions and performing some additional tests:

1. I attempted to run the DMIC sample on our custom NRF9160-based board after executing west update. Unfortunately, we encountered the same bus fault as before.

2. For comparison, I also ran the DMIC sample on an NRF5340DK. In this case, it functioned correctly without any issues, indicating that the problem seems to be specific to the NRF9160.

3. Further testing on an NRF9160DK board did not yield positive results. Although I couldn't confirm if it's the exact same issue faced with our custom board, the debug session was unsuccessful. An attempt to pause the execution led to an error message: "Internal error: Failed to update peripheral PDM_NS after memory reads." EDIT: It did however work without issues using SDK version 2.4.2.

Given these outcomes, it seems the problem might be specific to the NRF9160 in the context of SDK version 2.5.0.

Here is the overlay that I used for the NRF9160DK board:

&pinctrl {
	pdm0_default_alt: pdm0_default_alt {
		group1 {
			psels = <NRF_PSEL(PDM_CLK, 0, 18)>,
				<NRF_PSEL(PDM_DIN, 0, 19)>;
		};
	};
};

dmic_dev: &pdm0 {
	status = "okay";
	pinctrl-0 = <&pdm0_default_alt>;
	pinctrl-names = "default";
	clock-source = "PCLK32M_HFXO";
};

If you have any further insights or suggestions, they would be greatly appreciated.

[Raoul]

Hi,

Interesting, thank you for the details! That's really useful.

I'm not sure what the culprit is yet, but I'm looking into this and will keep you updated.

Best regards,

Raoul

[Raoul]

Hi again,

Could you try building your DMIC sample in the exact same as you did previously, but for the nrf9160dk_nrf9160 board? Meaning, the "secure" build. I'm assuming you've built for nrf9160dk_nrf9160_ns so far.

I'm curious if you would still get the same issue with the secure build.

I've discovered some recent cases that might possibly be related - It's possible that there is an error in some TF-M definitions which make peripherals inaccessible to the non-secure partition.

Best regards,

Raoul

[sensorbee-dev]

Hi Raoul,

Thank you for the suggestion. Following your advice, I built the DMIC sample for the nrf9160dk_nrf9160 board, targeting the secure build instead of the nrf9160dk_nrf9160_ns.

Interestingly, the DMIC sample worked with the secure build. This result aligns with your theory about a potential issue with the TF-M definitions affecting peripheral access in the non-secure partition.

If you have any more suggestions or need additional information from my tests, please let me know.

[Raoul]

Hi Sensorbee,

Thanks for confirming! It's all becoming clear now.

There were indeed two peripherals that were misnamed in the TF-M configuration in NCS v2.5.0. PDM was one of them.

If you're curious, you can see here: https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/8f6d96538f2221ac3a5c7df2e8fdbe3bd147d2ce/platform/ext/target/nordic_nrf/common/core/target_cfg.c#L829

that the PDM instance is referred to as PDM0, while the MDK refers to the PDM without any number: https://github.com/NordicSemiconductor/nrfx/blob/f147ea557d5e2a04cb95ab8328204bcf36d8f410/mdk/nrf9160.h#L2257

So there was a mismatch. Fortunately, the fix has already been commited: https://github.com/nrfconnect/sdk-trusted-firmware-m/commit/f2a462080edc42818003d052c57d777954220145

Apply those changes, and you should be good.

Best regards,

Raoul