Sporadic "crosstalk" from I2C into TDM mic input when ports and SW on the same slice or connector

[aclassifier]

I have struggled with some kind of sporadic "crosstalk" into my TDM mic pins: WS, SCK, but most "probable" the SD pin. (xTIMEcomposer 14.4.1)

This is complicated to explain, but I'll give it a try. The result is simple: all fixed when I2C for the display was moved away form the same tile[0] and connector as the mic input (both J1) to the I2C for the display been moved into another connector (J3) and tile[1]. xCORE-200 Explorer board.

I can hear the input also in the headset (similar TDM output). When I write to the SSD1306 display over I2C (400 kHz) at the same time (one time for each 32 ms spectrum) I had sporadic "crosstalk" when the display was written to, but when I ordered by buttons not to write to the display, all was fine. xCORE-200 Explorer board.

Both the TDM for the mic and that to the headset I have written myself, timing 2.048 MHz (average over 32 bits, one channel) without external PLL.

I used combined (but alone on a core I think) i2c_master from lib_i2c(5.0.0). Ports and i2c_master on tile[0] when I got the noise.

I use another I2C to write to a DAC board to get the spectra, that you see on the attachment. 0-4000Hz in 32.0 ms. Both distributed i2c_master_single_port and ports were on tile[1].

Since the latter did not influence the mic TDM input I tried to move the display i2c_master and ports to tile[1].

The sporadic "crosstalk" from I2C into TDM mic input disappeared when ports and SW were on different slices (from J1 to J3 on the xCORE-200 Explorer board).

For the noisy case I used the same pins as the board's internal I2C to the gyroscope and accelerometer. I unsoldered R49 and R52 as to disconnect those. The layout on the board does not explain the problem to me. I have twisted or braided all cables. Holding the display and the mic board away for each other, or some ad hoc screening did not help.

Any explanation or experience similar to this?

Is it the moving of the ports, or maybe some with the SW influencing each other? I run XTA on the mic TDM I need only 200 MHz proc for it.

Øyvind

In the attachment I have AGC for each 32 ms 16 kHz window. The scope FFT has its two first bins as 100% DAC out and AGC scaling of the DAC output as the second.

2024 02 26 BEEP-033 solved.pdf

[CousinItt]

Once more than five cores in a tile are busy then they are allocated less time, so that might be responsible. Alternatively you might really have some interference (or both!).

You could distinguish between them by adding a task that uses processor time but does not have any side effects that could give rise to radiated or conducted interference - e.g. it just communicates with something else or sets a pin to the same state - and see if the problem comes back. If it is due to processor load then you could set higher priority tasks to fast mode or, as you've already done, reduce the load by moving something off the tile.

[aclassifier]

Thanks!

Yes, I do move tile[0] task 6 to tile[1] task 5:
on tile[0]:

Code: Select all

1. Handle_Beep_BRRR_c_appl_task_b 
2. mic_ics52000_stereo_in_16kHz_task_m
3. mics_in_headset_out_c_task_a
4. headset_pcm5100_stereo_out_16kHz_task_h
5. [[combine]] several button tasks
6= [[combine]] but alone: i2c_master -----|
                                          |
on tile[1]                                |
1.    buffer_A_task_x                     |
2.    buffer_B_task_x                     |
3.    dsp_task_y                          |
4.    logger_task_iron                    |
5=    [[combine]] but alone: i2c_master --|
None: [distribute]] i2c_master_single_port

Probably not so relevant: the noisy version has this build:

Code: Select all

Constraints tile[0]: C:8/7 T:10/7 C:32/23 M:95960  S:45264  C:43848 D:6848
Constraints tile[1]: C:8/4 T:10/4 C:32/11 M:154012 S:110492 C:39444 D:4076

And the fine version has this build

Code: Select all

Constraints tile[0]: C:8/6 T:10/6 C:32/23 M:94760  S:45104  C:42812 D:6844
Constraints tile[1]: C:8/5 T:10/5 C:32/12 M:155236 S:110700 C:40456 D:4080

But adding a possible noise sender task as #6 on tile[0] now is worth a try!

And testing with

Code: Select all

void set_core_fast_mode_on(void)

("Sets the current logical core to run in fast mode") p201 of xTIMEcomposer User Guide (Rev B) would be new to me, but worth a try. I do this with conditional compilation anyhow, so it should be easy to check out.

Great response, thanks!
Øyvind

[aclassifier]

I added void set_core_fast_mode_on(void) in my mic PCM task (2.048 MHz) and did it get noisy! Yes! I don't think the sound even came through.

What might the explanation be for that?

p201 of xTIMEcomposer User Guide (Rev B)
Sets the current logical core to run in fast mode. The scheduler always reserves a slot for a logical core in fast mode regardless of whether core is waiting or an input or a select to complete. This reduces the worst case latency from a change in state happening to a paused input or select completing as a result of that change. However, putting a core in fast mode means that other logical cores are unable to use the extra slot which would otherwise be available while the core is waiting. In addition setting logical cores to run in fast mode may also increase the power consumption.

The MIC input PCM task delivers a stereo frame every 62.5 us (16 kHz) to a mux task.
The mux task scales the frame and sends it to the headphone PCM task, every 62.5 us, but that task also runs at 2.048 MHz.
So three logical cores are used for this.
The mux also sends the scaled frame down for DSP processing.
There is a figure in the unfinished blog note at My audio automatic gain control sw driver (AGC) notes