TWIM doesn't work using nRF5340DK with I/O voltage above 2.5V

[Yoshihiro Goto]

Hi,

TWIM does not work well with nRF5340DK as shown in the subject. The conditions are shown below.
- I/O voltage is not 1.8V. The waveform is distorted around 2.5V, though I wrote in the title that it does not work at 2.5V or higher.
- When using multiple TWIMs, only TWIM1 does not work well. If only one is used, it does not matter which one is used.
- The evaluation board from Fanstel (EVM-WM02-V6) has an I/O voltage of 3.3V, and I confirmed that TWIM does not work with this board.

The following are the results of my experiments.
- I confirmed that TWIM works with nRF7002DK. The I/O voltage of nRF7002DK is fixed at 1.8V.
- I tried to run the same firmware on nRF5340DK, but it returned TWIM error. When I looked at the waveforms on the oscilloscope, SCL did not output anything and SDA was fixed at about 1.5V.
- I added firmware to change the I/O voltage of nRF5340DK to 1.8V. This time it worked fine.

    if ((NRF_UICR_S->VREGHVOUT & UICR_VREGHVOUT_VREGHVOUT_Msk) != (UICR_VREGHVOUT_VREGHVOUT_1V8 << UICR_VREGHVOUT_VREGHVOUT_Pos)) {
		NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
		while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

		NRF_UICR_S->VREGHVOUT = (UICR_VREGHVOUT_VREGHVOUT_1V8 << UICR_VREGHVOUT_VREGHVOUT_Pos);

		NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
		while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

		/* a reset is required for changes to take effect */
		NVIC_SystemReset();
	}

From these verification results, I conclude that the nRF5340's TWIM does not work when the I/O voltage is set to anything other than 1.8V.
If something is wrong with my experiment, please point it out.
And... perhaps this is an errata?

[Håkon Alseth]

Hi,

 

Have you configured the TWI pins with pull-ups?

Here's an example:  RE: issues configuring LIS2DW12 sensor over I2C for custom board (nRF52840 SOC) 

 

Please also note that UART/TWI/SPI are shared peripherals (ie. shares address space):

https://infocenter.nordicsemi.com/topic/ps_nrf5340/chapters/memory/appmem.html?cp=4_0_0_4_2_0#instantiation

 

This means that UART0 cannot be enabled simultaneously with TWIM0 for instance.

 

Kind regards,

Håkon

[Yoshihiro Goto]

>Have you configured the TWI pins with pull-ups?

Ofcourse.

// To get started, press Ctrl+Space to bring up the completion menu and view the available nodes.

// You can also use the buttons in the sidebar to perform actions on nodes.
// Actions currently available include:

// * Enabling / disabling the node
// * Adding the bus to a bus
// * Removing the node
// * Connecting ADC channels

// For more help, browse the DeviceTree documentation at https://docs.zephyrproject.org/latest/guides/dts/index.html
// You can also visit the nRF DeviceTree extension documentation at https://nrfconnect.github.io/vscode-nrf-connect/devicetree/nrfdevicetree.html

&i2c1 {
	clock-frequency = <I2C_BITRATE_FAST>;
	status = "okay";
};

&i2c1_default {
	group1 {
		psels = <NRF_PSEL(TWIM_SCL, 1, 3)>, <NRF_PSEL(TWIM_SDA, 1, 2)>;
		bias-pull-up;
	};
};

&i2c1_sleep {
	group1 {
		psels = <NRF_PSEL(TWIM_SCL, 1, 3)>, <NRF_PSEL(TWIM_SDA, 1, 2)>;
		bias-pull-up;
		low-power-enable;
	};
};

>Please also note that UART/TWI/SPI are shared peripherals (ie. shares address space):

Yes, I know that too. Only minimal changes are made in the overlay file above, and the other settings are the default settings for nRF5340DK (or nRF7002DK).

>This means that UART0 cannot be enabled simultaneously with TWIM0 for instance.

I'm using TWIM1 as shown in the overlay file, because it is on by default in nRF5340DK.

[Yoshihiro Goto]

Upload the video.
https://drive.google.com/file/d/1tPYrc4hob0pndZ-uuJW6KxaM0M6_UA2_/view?usp=drive_link

First power on with 3.0V I/O but I2C is not working. Then change to 1.8V and power on and it works properly. When I change it back to 3.0V and turn it on again, it still does not work.

[Yoshihiro Goto]

Please wait a minute. It could be a my hardware problem. I'm not convinced that it doesn't work with the evaluation board.

[Håkon Alseth]

Hi,

 

Yoshihiro Goto said:

Please wait a minute. It could be a my hardware problem. I'm not convinced that it doesn't work with the evaluation board.

Thanks for updating. Let me know if there's anything I can help with.

 

As a generic note, please note that "bias-pull-up" means internal pull-resistors in the GPIO pad, which are ~13 kOhm. This is not enough to drive a I2C 400 kHz signal, but it will work for 100 kHz. If you do not have external pull-up resistors in addition; you can try to lower the speed to 100 kHz (define "I2C_BITRATE_STANDARD")

 

Kind regards,

Håkon

[Yoshihiro Goto]

Sorry for the late reply.

My guess is probably insufficient I/O drive capability. the I2C pull-up resistor was small, so a large current was flowing.

I apologize for the trouble with my assumption.
I'll close this thread now.