TWI Manager - TWI delayed after start condition

RE: TWI Manager - TWI delayed after start condition

Jørgen Holmefjord — Fri, 18 Feb 2022 15:31:21 GMT

Hi Dylan,

I would also not expect a reduction in priority to affect this, but I also would not expect any delay before the address is output at all.

If you could find a way to help us reproduce this behavior on a DK, we could look further into it, but otherwise I think it will be hard to debug further.

Alternatively, if you can confirm that this happens with any/no I2C slave device connected to the bus, and can provide your code, we can try to reproduce it on our DK ourselves.

Best regards,
Jørgen

RE: TWI Manager - TWI delayed after start condition

underpickled — Fri, 04 Feb 2022 19:55:09 GMT

Hi Jørgen,

I can't say for sure if this alone solved it, but I fixed another issue related to the TWI interrupt priority interfering with the softdevice interrupt priority. Basically I had to reduce the TWI interrupt priority from HIGH to LOW_MID to get BLE streaming working, and since then I've looked back at the traces and they are much more stable. There is occasionally a 90-120 us gap, but that's much more tolerable than 2-4 ms and no longer concerning at all. Do you think that could have addressed the issue somehow? I wouldn't expect a priority reduction to *reduce* delays, but maybe you have some insight into that.

Thanks,

Dylan

RE: TWI Manager - TWI delayed after start condition

underpickled — Mon, 31 Jan 2022 20:35:01 GMT

Hi,

Yes, both buses have two of the same slave devices (total of 4, they only have I2C interfaces and only two available addresses each, hence the two bus implementation). I haven't tried reproducing this on a DVK (I'm not sure I have the hardware available to replicate the exact setup). It'll be tricky, but I can try to cut the clock trace and solder a resistor in-line.

Thanks,

Dylan

RE: TWI Manager - TWI delayed after start condition

Jørgen Holmefjord — Mon, 31 Jan 2022 17:27:42 GMT

Hi,

Are you interfacing the same slave TWI device on the bus on the second board that is failing? Have you been able to reproduce this behavior on one of our DKs?

One of my colleagues suggested to connect a small resistor on the clock pin, to measure analog channels before and after the resistor to find if it's the slave or master that is holding the clock low here. Would you be able to measure that?

P0.11 should noe have any special features that could affect the TWI peripheral as far as I can see.

Best regards,
Jørgen

RE: TWI Manager - TWI delayed after start condition

underpickled — Fri, 28 Jan 2022 02:16:40 GMT

I've got another interesting example of this here:

devzone.nordicsemi.com/.../TWI0_5F00_1_5F00_delays.sal.zip

This is running basically the same code, but on a different board with two TWI buses used. I have two TWI manager instances. On this board, the delay only seems to pop up in TWI1 (SCL: P0.11, SDA: P1.9) and does not appear in TWI0 (SCL: P0.5, SDA: P0.4). I also notice the periodicity is different.

I don't know if this could be related, but pin 0.11 is the SDA line in the original ticket.

RE: TWI Manager - TWI delayed after start condition

underpickled — Tue, 25 Jan 2022 17:32:10 GMT

I'll give that a try and report back. In the meantime, here's the zipped logic trace.devzone.nordicsemi.com/.../nrf52_5F00_TWI_5F00_delay_5F00_after_5F00_SC.sal.zip

Just to clarify the static placements, do you mean the transfer buffers, the queue, every definition related to TWI, or just a subset of those?

[Update]: As I'm looking into this, while the RAM/Memory map tells me which addresses belong to each AHB slave RAM region, I can't find anything indicating which peripherals are using which AHB slave. I can't tell if it's safer to put everything in RAM0 or RAM8. Also, what is the preferred method of specifying an address for static allocations? I tried using the syntax in the EasyDMA example (static foo[n] __at__ 0xADDR), but it would not compile.

[Update 2]: I was able to move the array of transfers as well as the other data used to support it into a section in AHB RAM8 (0x20018000, previously they were being mapped in the 0x20002--- range or so). The behavior is the same. I also notice that this glitch appears to be periodic, happening reliably every ~1100ms.

[Update 3]: I have also tried disabling BLE advertising, as well as not initializing BLE to begin with, but it appears to still be happening.

Thanks,

Dylan

RE: TWI Manager - TWI delayed after start condition

Jørgen Holmefjord — Tue, 25 Jan 2022 14:21:39 GMT

Hi,

The only thing that comes to mind would be that a higher priority AHB master accesses the same RAM block/AHB slave and blocks the TWIM peripheral. Just to rule this out, can you test to statically place all TWIM buffers in a RAM section not used by any other peripherals or the CPU, and see if the issue still persists? See Random access memory for details about which RAM addresses/sections are mapped to which AHB slave.

Looks like the CSV file can't be imported in Saleae Logic. Can you try to zip the logic trace file and upload that? I belive the site should accept .zip files.

Best regards,
Jørgen

RE: TWI Manager - TWI delayed after start condition

underpickled — Mon, 24 Jan 2022 17:50:51 GMT

Hi Jørgen,

I'm using SDK 17.1 and Easy DMA is enabled in sdk_config.h (though each transfer loaded into the queue has its own static pointers to the data to send and received). Is it possible the softdevice is causing this interruption? I know that's theoretically possible, but it seems odd that it would cause an initiated TWI transfer to stall.

I'm using pins 0.11 (SDA) and 0.12 (SCL). I could try different pins, but it would result in some fly-wires that might degrade performance.

Regarding clock stretching, I don't have other devices to immediately test with this board, but as you mentioned it happens before the address (I find this is always the case), which seems to rule out the slave stretching the clock. The slave devices are TI FDC2214, for the record. I generally expect predicable behavior from TI chips.

I'm attempting to attach the full Saleae trace file, but this isn't letting me upload it in this comment. I'll see if I can add it to the original post.

[Edit]: It appears to only let me upload a CSV. The trace file is much smaller and probably easier to work with, but it won't allow me to upload it. Let me know if I can send it over somehow.

devzone.nordicsemi.com/.../digital.csv

Channels 0 and 1 are SCL and SDA, respectively. Channels 2 and 3 are the interrupts that trigger the burst transfer.

Thanks for your help,

Dylan

RE: TWI Manager - TWI delayed after start condition

Jørgen Holmefjord — Mon, 24 Jan 2022 16:48:37 GMT

Hi,

Which SDK version are you using?

Is the TWI instance configured to use EasyDMA? This is configured through the following configs in your sdk_config.h file:

// <q> TWI0_USE_EASY_DMA  - Use EasyDMA (if present)
#ifndef TWI0_USE_EASY_DMA
#define TWI0_USE_EASY_DMA 0
#endif


// <q> TWI1_USE_EASY_DMA  - Use EasyDMA (if present)
#ifndef TWI1_USE_EASY_DMA
#define TWI1_USE_EASY_DMA 0
#endif

TWI will be more affected by other interrupts in your application, as you need to update the data pointer for each byte being sent/received. However, according to the transfer diagrams, both TWI and TWIM should send the address and send/receive at least one byte before there is any pause in transmission (TWI/TWIM).

Which GPIOs are you using for SCL/SDA? Have you tried different pins?

Are you seeing this behavior with other TWI/I2C slaves, or could it be the slave doing some clock stretching, etc? Would be a bit strange if this happens before the address is written to the bus.

Can you share the full logic trace file that shows this happening?

Best regards,
Jørgen