I'm using zephyr with a custom board (nrf52840) which has a ssd1306 OLED. I have it configured to use i2c0 and is working fine with lvgl.
When I try to enable uart0 (using the async API), the ssd1306 device initialization fails. I can confirm that both display and uart work as expected individually. When enabled together is when this issue occurs. I have triple checked that they don't have any overlapping pin configurations.
Is there anything else I should be checking?
Hi,
Which GPIOs are you using for I2C0?
I have triple checked that they don't have any overlapping pin configurations.
Have you checked that the RTS/CTS does not overlap? That is by-default P0.05 to P0.08 on the nRF52840-DK.
Kind regards,
Håkon
I have my own board definition. In this board, I define the following:
&pinctrl {
uart0_default: uart0_default {
group1 {
psels = <NRF_PSEL(UART_TX, 1, 11)>;
};
group2 {
psels = <NRF_PSEL(UART_RX, 1, 12)>;
bias-pull-up;
};
};
uart0_sleep: uart0_sleep {
group1 {
psels = <NRF_PSEL(UART_TX, 1, 11)>,
<NRF_PSEL(UART_RX, 1, 12)>;
low-power-enable;
};
};
i2c0_default: i2c0_default {
group1 {
psels = <NRF_PSEL(TWIM_SDA, 0, 4)>,
<NRF_PSEL(TWIM_SCL, 0, 5)>;
};
};
i2c0_sleep: i2c0_sleep {
group1 {
psels = <NRF_PSEL(TWIM_SDA, 0, 4)>,
<NRF_PSEL(TWIM_SCL, 0, 5)>;
low-power-enable;
};
};
};
And the the ssd1306 entry:
&i2c0 {
status = "okay";
ssd1306_128x64: ssd1306@3c {
compatible = "solomon,ssd1306fb";
reg = <0x3c>;
width = <128>;
height = <64>;
segment-offset = <0>;
page-offset = <0>;
display-offset = <0>;
multiplex-ratio = <63>;
segment-remap;
com-invdir;
prechargep = <0x22>;
};
};
Can you please share the zephyr.dts file, located in build/application-name/zephyr folder?
The relevant sections:
/ {
soc {
uart0: uart@40002000 {
reg = < 0x40002000 0x1000 >;
interrupts = < 0x2 0x1 >;
compatible = "nordic,nrf-uarte";
status = "okay";
current-speed = < 0x1c200 >;
pinctrl-0 = < &uart0_default >;
pinctrl-1 = < &uart0_sleep >;
pinctrl-names = "default",
"sleep";
phandle = < 0x12 >;
};
i2c0: i2c@40003000 {
#address-cells = < 0x1 >;
#size-cells = < 0x0 >;
reg = < 0x40003000 0x1000 >;
interrupts = < 0x3 0x1 >;
easydma-maxcnt-bits = < 0x10 >;
zephyr,pm-device-runtime-auto;
compatible = "nordic,nrf-twi";
pinctrl-0 = < &i2c0_default >;
pinctrl-names = "default";
status = "okay";
ssd1306_128x64: ssd1306@3c {
compatible = "solomon,ssd1306fb";
reg = < 0x3c >;
width = < 0x80 >;
height = < 0x40 >;
segment-offset = < 0x0 >;
page-offset = < 0x0 >;
display-offset = < 0x0 >;
multiplex-ratio = < 0x3f >;
segment-remap;
com-invdir;
prechargep = < 0x22 >;
};
};
};
};
Hi,
Those are not the relevant parts from the file. In the future, please do not truncate information when asked for specific files (or other things, like build logs etc).
The segment I am after is the pinctrl definitions, as you have used the same definition as in the board itself.
In the board, the RTS/CTS is also defined, which are inherited when you re-use the same pinctrl names. So, if you rather make a new pinctrl definition, like this:
&pinctrl {
my_uart0_default: my_uart0_default {
group1 {
psels = <NRF_PSEL(UART_TX, 1, 11)>;
};
group2 {
psels = <NRF_PSEL(UART_RX, 1, 12)>;
bias-pull-up;
};
};
my_uart0_sleep: my_uart0_sleep {
group1 {
psels = <NRF_PSEL(UART_TX, 1, 11)>,
<NRF_PSEL(UART_RX, 1, 12)>;
low-power-enable;
};
};
...rest of definitions
};
&uart0 {
status = "okay";
pinctrl-0 = < &my_uart0_default >;
pinctrl-1 = < &my_uart0_sleep >;
pinctrl-names = "default",
"sleep";
...rest of configuration
};
Does it then work?
Kind regards,
Håkon
Like I said, I'm defining my own board, so there isn't anything to inherit from.
Here is my pinctrl definitions:
/ {
pinctrl: pin-controller {
uart0_default: uart0_default {
phandle = < 0x2 >;
group1 {
psels = < 0x2b >;
};
group2 {
psels = < 0x100002c >;
bias-pull-up;
};
};
uart0_sleep: uart0_sleep {
phandle = < 0x3 >;
group1 {
psels = < 0x2b >,
< 0x100002c >;
low-power-enable;
};
};
i2c0_default: i2c0_default {
phandle = < 0x4 >;
group1 {
psels = < 0xc000004 >,
< 0xb000005 >;
};
};
i2c0_sleep: i2c0_sleep {
group1 {
psels = < 0xc000004 >,
< 0xb000005 >;
low-power-enable;
};
};
};
};
Hi,
Your custom board has external pull resistors on SDA/SCL? What is the speed? If using 400 kHz mode, you will need strong pulls, in the order of < 5kOhm. I suggest that you scope your pins on both scenarios, share run time logs of both working and non-working scenarios.
Kind regards,
Håkon
Hi,
Your custom board has external pull resistors on SDA/SCL? What is the speed? If using 400 kHz mode, you will need strong pulls, in the order of < 5kOhm. I suggest that you scope your pins on both scenarios, share run time logs of both working and non-working scenarios.
Kind regards,
Håkon
I have 4.7K external pull-ups on SCL and SDA lines. The clock speed was unset till now, but setting it to 100 kHZ (with `clock-frequency = <I2C_BITRATE_STANDARD>;` in the i2c0 node) has no effect.
Hi,
On the nRF52-series devices, the UART is not a shared resource, which it is on the nRF53-series and on-ward.
This means that TWIM0 and UARTE0 can be used simultaneously without any issues, provided that they do not create a pin conflict for each other. Ie. there is no reason why these two peripherals cannot coexist on the nRF52840.
sidcha said:I can post scope screenshots and logs tomorrow when I get back to my desk.
perfect, this would be great.
Kind regards,
Håkon
Thanks for the response. I'm aware that those peripherals are non-shared. I was wondering if anything else was shared, such as IRQs, DMAs etc.,
Here is a scope capture of the failure:
I found Zephyr tries to send a single 0 byte to the OLED at address 0x3c. This can be seen in the capture as well.
Hi,
There is no direct error in the image that you show. The sensor ACK, by keeping the line low at the LSBit.
Do you have any runtime logs or similar? What happens in a normal scenario?
Is this the very first transaction, or is it in the middle of the init? There is so much information that is not presented here. You need to provide traces/logs from boot-up.
sidcha said:I was wondering if anything else was shared, such as IRQs, DMAs etc.,
No, they are not shared between TWIM0 and UARTE0 on the nRF52840.
Kind regards,
Håkon
i2c_nrfx_twi_transfer()
i2c_nrfx_twi_msg_transfer()
ret = k_sem_take(&data->completion_sync, I2C_TRANSFER_TIMEOUT_MSEC);
if ret != 0:
/* Whatever the frequency, completion_sync should have
* been given by the event handler.
*
* If it hasn't, it's probably due to an hardware issue
* on the I2C line, for example a short between SDA and
* GND.
* This is issue has also been when trying to use the
* I2C bus during MCU internal flash erase.
*
* In many situation, a retry is sufficient.
* However, some time the I2C device get stuck and need
* help to recover.
* Therefore we always call i2c_nrfx_twi_recover_bus()
* to make sure everything has been done to restore the
* bus from this error.
*/
nrfx_twi_disable(&config->twi);
(void)i2c_nrfx_twi_recover_bus(dev);
ret = -EIO;