ssd1306 i2c not working with nrf51822

[phob]

Hi, i am using oled ssd1306 i2c with nrf51822. I am using peripheral mode and SDK v10.0. i choose this sdk version because of length i want to sent at one go that is 1024. I have connected oled to pin 18 and pin 20 for SDA and SCL respectively.

I took twi_sensor code for reference and i merged oled code in that. first i tried led blinking and it working without problem. But oled is not at all working.

I checked on logic analyser, i found nrf chip is not communicating over i2c. i didn't see any signal changes on those pins. i have attached logic analyser screen shot.

i have updated code on github. github.com/.../olednrf51

[MartinBL]

Hi,

I interpret "pin 18 and pin 20 for SDA and SCL respectively." as

• SDA -> pin 18
• SCL -> pin 20

In your code on github you have it the other way around. Am I misunderstanding?

If this isn't the issue I suggest that you double, triple, and quadruple check your wiring, make sure that the SSD is powered on, and make some code like this to check whether the SSD is responding at all.

[phob]

now it not getting stuck. But only few logic level change on SDA and SCL pins i could see using Logic analyser. 

I have doubt about NRF_DRV_TWI_TX_DONE event which comes in twi_handler() function. Do we need to send next trasnsaction from handler function after getting TX_DONE event?

[MartinBL]

You have implemented your TWI driver in non-blocking mode. If you do this you have to wait for a TWI callback before you start the next TWI transfer. In OLED_init() you effectively call nrf_drv_twi_tx() over and over without waiting for the transfer complete callbacks and this makes the TWI communication fail. Please have a look at the TWI Basic usage documentation.

[phob]

Yes i tried non blocking as well then NRF chip get stuck there only. I was planning to with Latest SDK. 

Is it possible to send 1024 bytes continuously without restart or stop start condition?

As per latest TWI driver we can send 256 bytes only. 

[MartinBL]

The drivers are made for 255 bytes only, but I suppose you can modify the it or make your own to transfer more bytes in one go. Note though, that there is a ''no_stop' flag in the function nrf_drv_twi_tx(). If the flag is set, then the stop condition is not generated on the bus after your transfer has completed successfully, but the drivers will still generate a 'repeated start' condition. 

[phob]

Is there modified code available? I was looking into code but structure field itself is 8bit and it is used at many places. function twi_xfer also using same structure. I could not find the defination of this function. 

[MartinBL]

The SDK team says a 16-bit enabled driver will be released in SDK 15 which will be available in a not too distant future. If you are in a hurry, you could try to change all the 8-bit fields to 16-bit fields yourself. The definition of twi_xfer is located in nrf_drv_twi.c. This function is not used anywhere outside this file, and has no declaration in header files. 

[Spirit]

MartinBL
We still do not have a 16-bit enabled driver, neither in a SDK 15 nor in a SDK 15.1 ;)

[MartinBL]

That unfortunately seems to be correct. I'm not sure what has happened and I can't find the info I relied on 7 months ago.

Anyway, the MAXCNT registers (maximum number of bytes in the transmit buffers) in the TWI is only 8 bit wide, so the HW will actually never be able to transmit more than 255 bytes at a time. However, you can use the EasyDMA list function and chain multiple transfers. You can use PPI and/or shortcuts to make the transfers completely autonomous and independent of the CPU and interrupts. This allows you to transfer buffers that are a lot longer than just 255 bytes. You are basically just limited by the amount of RAM available for your buffer.

[MartinBL]

That unfortunately seems to be correct. I'm not sure what has happened and I can't find the info I relied on 7 months ago.

Anyway, the MAXCNT registers (maximum number of bytes in the transmit buffers) in the TWI is only 8 bit wide, so the HW will actually never be able to transmit more than 255 bytes at a time. However, you can use the EasyDMA list function and chain multiple transfers. You can use PPI and/or shortcuts to make the transfers completely autonomous and independent of the CPU and interrupts. This allows you to transfer buffers that are a lot longer than just 255 bytes. You are basically just limited by the amount of RAM available for your buffer.