• State Suggested Answer
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 65 subscribers
  • Views 322 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 326910
Options

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?

Parents Reply Children
  • 0 in reply to Håkon Alseth

    >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.

  • 0 in reply to 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.

  • 0 in reply to 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.

  • 0 in reply to Yoshihiro Goto

    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

  • 0 in reply to Håkon Alseth

    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.

Related