pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Sat, 22 Feb 2025 22:48:15 GMT

After testing the new layout works.

In it the BME280 starts ON and its power is not controllable.
Meaning its directly connected to the battery.

Summarizing.
The BME280 zephyr drivers are has of now ready to handle the hardware SPIM problem 58 of the nRF52832.
The work around developed (SPI) works in normal situations.
However, in some edge cases like the one in this thread it may fail inexplicably.
So, the solutions is that when developing with the nRF52832's SPI either:
- Try to avoid hardware complications, especially with the power of the BME280 (this is what i did)
- If this are necessary, make the BME280 start ON (this seams to work for me)
A less useful solutions is to alter the SoC, for example, to the new nRF54 line (not sponsored).

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Fri, 21 Feb 2025 23:05:02 GMT

Reopening since after further testing found that the BME280 drivers are not compatible with the SPIM for the nRF52832.

This is due to them not complying with workarround 58, of 1 byte transfers.

My only chance now is altering the PCB layout and hopping for the best with the normal SPI. I guess.

Will know tomorrow.

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Fri, 31 Jan 2025 20:54:16 GMT

Ok I shall do that.

But in relation to this statement:

Although I can't find any documentation of it, I believe I have heard something like the SPI driver is deprecated, and you should use the SPIM driver instead, as it has no disadvantages compared to the SPI driver.

The DevZone academy intermediate course show that for the nrf52 dk (nrf52832) the SPI module is the indicated to use because of the errata 58. This might need fixing.

https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-5-serial-peripheral-interface-spi/topic/exercise-1-10/

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

Edvin — Thu, 30 Jan 2025 09:54:06 GMT

Hello,

Sorry for the late reply.

The SPI doesn't have DMA, which handles your queues/buffers without the need of the CPU. Therefore, in most cases, the SPIM driver is preferred.

If you say that the nrfx_spi_xfer() finishes too quickly, it may be that it is not blocking, and hence only queues the transaction. Then your application goes on to the next SPI xfer before the first one finishes, messing up the data flow. Although I can't find any documentation of it, I believe I have heard something like the SPI driver is deprecated, and you should use the SPIM driver instead, as it has no disadvantages compared to the SPI driver.

So I believe the case is that since the SPI driver is not blocking, other drivers may not wait for a transaction to finish before calling the next transaction, causing the next transaction to return an error.

[quote user="TheLittleFish"]nrfx_spi_xfer() function in spi_nrfx_spi.c is finishing too quickly.[/quote]

Indeed. It will finish/return before the transaction is complete, looking at the source code:

    if (p_cb->transfer_in_progress)
    {
        err_code = NRFX_ERROR_BUSY;
        NRFX_LOG_WARNING("Function: %s, error code: %s.",
                         __func__,
                         NRFX_LOG_ERROR_STRING_GET(err_code));
        return err_code;
    }
    else
    {
        ...

So if it is not a problem, I suggest you use the SPIM driver. Since this uses DMA, it is capable of handling the buffer, adding to it instead of trying to hijack it.

Best regards,

Edvin

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Fri, 24 Jan 2025 17:06:08 GMT

Any idea why this could be happening?

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Thu, 09 Jan 2025 14:29:57 GMT

Just tried the spim and it works, so its a spi problem.

My guess, the transfer_next_chunk() > nrfx_spi_xfer() function in spi_nrfx_spi.c is finishing too quickly.

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Tue, 07 Jan 2025 03:52:25 GMT

Will try to use the SPIM.

Also, my bad, I'm not using P0.10 to control de CS of the BME, its the P0.11.

P0.10 and P0.09 are in use but for other stuff.

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

Edvin — Mon, 06 Jan 2025 12:00:34 GMT

Can you try to use the SPIM driver instead of the SPI, for debugging purposes?

Also, note that the P0.10 is the NFC pin. I don't understand why it would behave any different. Do you happen use P0.09 for anything?

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Fri, 03 Jan 2025 15:59:10 GMT

What pin do you use for your SPI - CS?

P0.10 with Active low, open drain. <&gpio0 10 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>.

And is that being used by the other connection to the dongle?

No.

How do you connect this dongle/second board?

USB-C, but only the connector the protocol is not utilized.

What protocol does that and the nRF use to communicate?

The other dongle contains an RTD Wheatstone bridge so the "connection" is made with an ADC. Meaning that the voltage divider points of the bridge pass through the connector directly to an analog pin for the ADC.

And particularly, what SPI instance are you using for the bme, and what instance of the peripheral used in your dongle connection are you using?

spi instance 1. "compatible = "nordic,nrf-spi"", so normal SPI not SPIM.

And did you add CONFIG_SOC_NRF52832_ALLOW_SPIM_DESPITE_PAN_58 to your prj.conf? Or is it included in your build\zephyr\.config file?

Since im utilizing SPI and not SPIM did not see this. Checking the "spi_nrfx_spi.c" and the "spi_nrfx_spim.c" this config is present only in the spim file. Will still try and see if it works.

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

Edvin — Fri, 03 Jan 2025 14:14:55 GMT

And did you add CONFIG_SOC_NRF52832_ALLOW_SPIM_DESPITE_PAN_58 to your prj.conf? Or is it included in your build\zephyr\.config file?

Best regards,

Edvin

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

Edvin — Fri, 03 Jan 2025 14:08:19 GMT

What pin do you use for your SPI - CS? And is that being used by the other connection to the dongle? How do you connect this dongle/second board? What protocol does that and the nRF use to communicate?

And particularly, what SPI instance are you using for the bme, and what instance of the peripheral used in your dongle connection are you using?

Best regards,

Edvin

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Sat, 21 Dec 2024 21:48:10 GMT

I found this bug, that exist in the version im using (2.7.0).

Asynchronous spi chip select deasserts early

Will try it and say something.

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Sat, 21 Dec 2024 01:04:15 GMT

Adding CONFIG_NRFX_SPI_LOG=y to the configs makes it work for some reason.

Maybe the extra logs are stopping the SPI form doing something, idk...

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Fri, 20 Dec 2024 23:15:11 GMT

My bad the -134 appeared after some debugging, its the PM_DEVICE_ACTION_RESUME.

After some time of looking at the code i noticed that the problem is getting more complex so i am going to give extra information.

Description: My system (main board) contains a port, that I utilize to connect a second board (dongle) with an Wheatstone bridge with a RTD to measure temperature. When the main board and dongle are disconnected, the bme280 fine, but if they are connected the bme280 does not answer on the main board power-up. To note that if the dongle is connected after the power-up stuff is complete the bme280 keeps working with no issue.

I placed the board in a data analyzer and verified the SPI connections. The results show that without the dongle the SPI works correctly, but with the dongle the SPI's CS pin dies mid way.

Without dongle:

With dongle:

What seems weird is that the rest of the SPI pins seem fine since they continue transmitting even with the CS dying.

Will continue looking...

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

Edvin — Fri, 20 Dec 2024 21:43:36 GMT

[quote user="TheLittleFish"]

Removing the suspend gives the error -120 or EALREADY meaning the socket is already connected

[/quote]

Sorry for not being precise. I meant if you remove both the suspend and resume, so that it should be active. Does the issue occur if you do not disable it and re-enable it? Or only when you suspend and resume it?

[quote user="TheLittleFish"]The EIO means that the spi is not ready, so i placed a k_sleep(K_MSEC(500)) in between the pm_device_action_run() functions and we are back to the previous -134 error[/quote]

What -134 error is this? I can't see any mentions of it earlier. What function is it that returns -134?

Please note that I will be out of office until the beginning of January. I am sorry for the inconvenience, but I will not be able to reply before that. The same goes for most of our team, so if you create a new ticket, I can't guarantee that someone will be able to look into it before January.

Best regards,

Edvin

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Fri, 20 Dec 2024 01:43:22 GMT

Also the error as evolved now its a spi_transcive error of value -5 (EIO)

*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
[00:00:00.004,058] <inf> Log_Main: Starting Beacon Demo

Bluetooth initialized
Beacon started, advertising as D9:3C:7C:7D:A5:CE (random)
DONE
[00:00:00.507,934] <dbg> BME280: bme280_reg_read_spi: spi_transceive FAIL -5

[00:00:00.507,965] <dbg> BME280: bme280_chip_init: ID read failed: -5
[00:00:00.507,995] <err> Log_Main: BME device pm RESUME failed: -5

EDIT: The EIO means that the spi is not ready, so i placed a k_sleep(K_MSEC(500)) in between the pm_device_action_run() functions and we are back to the previous -134 error.

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Fri, 20 Dec 2024 01:26:49 GMT

It seems I found the problem.

Enabling CONFIG_BT_DEBUG_LOG=y in the configurations causes the issue.

When to check and noticed that it is deprecated.

I found the CONFIG_BT_LOG_LEVEL_CHOICE, for an alternative.

I enabled CONFIG_BT_HCI, CONFIG_LOG, and CONFIG_BT_LOG_LEVEL_INF to maintain the Logs.

The error still persists.

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

TheLittleFish — Thu, 19 Dec 2024 00:27:12 GMT

Thank you for the reply.

If you comment out the sensor_channel_get(), do you still see this in the log?

Yes commenting any code after the pm RESUME still gives this error

And what happens if you do not suspend and resume the BME device?

Removing the suspend gives the error -120 or EALREADY meaning the socket is already connected

arm-none-eabi-addr2line stuff

This points to line 297 of the v2.7.0/modules/hal/nordic/nrfx/drivers/src/nrfx_spi.c in function transfer_byte and this function is called in the irq_handler (same file) line 455.

I don't suppose you are able to replicate the same behavior without the actual sensor, just using a DK?

No clue, will try tomorrow

RE: pm_device_action_run gives MPU FAULT if bme280 ID is bad (0x00)

Edvin — Wed, 18 Dec 2024 21:41:56 GMT

Hello,

[quote user=""]

My problem is that the MPU FAULT only happens when the while is ran as is. If a sensor_channel_get(...) function or the ble function are commented the MPU FAULT no longer appears.

[/quote]

If you comment out the sensor_channel_get(), do you still see this in the log?

<dbg> BME280: bme280_chip_init: bad chip id 0x0

And what happens if you do not suspend and resume the BME device?

And if you run the application as is one more time, and take note of the r14/lr and r15/pc registers (in this log, they were 0x00017881 and 0x00017820, respectively. If you then, without re-building the application, run the command:

arm-none-eabi-addr2line -e build\zephyr\zephyr.elf 0x00017881

arm-none-eabi-addr2line -e build\zephyr\zephyr.elf 0x00017820

(but with the addresses from the latest log). What does it say? You may need to adjust the path to the .elf file if you are using sysbuild, and you need to install armgcc to use arm-none-eabi-addr2line. Alternatively, if you have a terminal with the toolchain from NCS, you can use arm-zephyr-eabi-addr2line. If you can't get the addr2line tool working, you can send me your build folder, and the addresses from the log in that build.

I don't suppose you are able to replicate the same behavior without the actual sensor, just using a DK?

Best regards,

Edvin