Imu, pdm & ble同时启动时的数据问题, Simultaneous startup data issues

Products & Technology XIAO
,
1

我在用XIAO nRF52840 SENSE。
启用了DMA方式读取104Hz的IMU，41667Hz / 16000Hz的PDM并通过BLE实时发送。

  1. 当PDM不开启时，IMU通过BLE发送，在上位机读取后，IMU都是连续且稳定的。
  2. 当IMU和PDM都开启，BLE未连接时，IMU的数据也是连续且稳定的。
  3. 当IMU和PDM都开启，BLE连接后，IMU数据会有两帧数据都为0值，而且是间歇性的发生。

通过报文打印检查过，在数据异常时，IMU的双缓冲数组的数据都是0，可以排除是解析导致的异常。但是1和2也能说明IMU的读取和解析是正确的。尝试过16KHz和41.667kHz，情况没有变化。 BLE采用了247， 1M，间隔7.5ms。
如果是BLE开启后挤占CPU时间的问题，修改PDM的采样率是不是应该有好转？

有其他朋友遇到过类似的问题么，现在碰到的问题可能是什么原因导致的？

2

I am using XIAO nRF52840 SENSE.
I want to get IMU data via DMA @ 104Hz, PDM data @16kHz/41.667kHz, and send the data via BLE @ 247,1M, gap = 7.5ms.

  1. when enable IMU, disable PDM, the IMU data can be send via BLE correctly.
  2. when enable both IMU and PDM, the BLE is disconnected, the IMU data are also correct.
  3. when enable both IMU and PDM, and connected BLE and send realtime data. the IMU data will be about 0 in some frame. about 1 frame in 10 frames.
    In the situation, the IMU data from DMA buffer are already 0, so I think it is none business of send data via BLE or parse data.
    I try to change PDM from 41.667kHz to 16kHz, it appears no improvement.

Anyone know why and what happened. What can I do to solve this problem?

3

Hi there,

SO , it’s been a minute, always good stuff you bring and ask :+1:

Its a contention issue, the BLE (radio is the highest interrupt priority), the DMA is next, the PDM is LAST :grin:
the BLE interuppts causes a delay in returning he DMA start memory location basically, the short connection interval cuases that. The PDM has on ly a two sample buffer so it complicates the DMA and the data gets a ZERO…

Switch to DPPI /PPI :+1:
Do not rely on CPU interrupts to trigger the next IMU DMA transfer. Use hardware PPI/DPPI to connect the IMU data-ready GPIO pin directly to the SPI/I2C START task. This eliminates CPU interrupt latency from the transfer trigger path.
Also Increasing the interval to 15 ms–30 ms while transmitting multiple packets per connection event gives the CPU larger continuous time slices to handle peripheral ISRs and buffer swapping.
Check your dev tree and Kconfig for proper priority in Zephyr and with IMU instead of the PING-PONG double buffer , use a fifo 3 or 4 elements for the Queue so a brief delay in consumption does not result in reading an empty/unpopulated slot.

Give it a go , and let us Know :grin:

HTH
GL :slight_smile: PJ :v: