TWI on nRF51822

RE: TWI on nRF51822

Ole Morten — Thu, 01 Aug 2013 09:53:28 GMT

To clean things up, I'd be happy if you could evaluate the answers you have received and accept one of them if you feel it's sufficient. If not, it might be useful to expand your question a little and provide further information.

RE: TWI on nRF51822

Tielman — Wed, 03 Jul 2013 05:13:37 GMT

Hi Tom

If the softdevice is enabled, you can not access the PPI directly as you have done in your code. You have to use the softdevice API to access the PPI. The PPI is mentioned as restricted in the softdevice specification, which means you must access it via the sd API. As example, the following code strip

NRF_PPI->CH[0].EEP = (uint32_t)&NRF_TWI1->EVENTS_BB;
NRF_PPI->CH[0].TEP = (uint32_t)&NRF_TWI1->TASKS_SUSPEND;

should be replaced by sd_ppi_channel_assign(0, &NRF_TWI1->EVENTS_BB, &NRF_TWI1->TASKS_SUSPEND);

All the NRF_PPI references need to be replace by sd_ppi_* equivalent commands.

I did not notice that your softdevice is enabled (or disabled for that matter) in your code, but the code file you sent is probably a summarized version of your actual code? If you are using BLE in your project, then it is probably enabled in which case you have to modify the code as I have indicated above. As quick reference, simply do the following replacements in your code (with the above example as well):

NRF_PPI->CHENCLR = PPI_CHENCLR_CH0_Msk; should be sd_ppi_channel_enable_clr(PPI_CHENCLR_CH0_Msk);

NRF_PPI->CH[0].TEP = (uint32_t)&NRF_TWI1->TASKS_STOP; should be sd_ppi_channel_assign(0, &NRF_TWI1->EVENTS_BB, &NRF_TWI1->TASKS_STOP);

NRF_PPI->CH[0].TEP = (uint32_t)&NRF_TWI1->TASKS_SUSPEND; should be sd_ppi_channel_assign(0, &NRF_TWI1->EVENTS_BB, &NRF_TWI1->TASKS_SUSPEND);

Hope this helps

RE: TWI on nRF51822

Tom — Tue, 02 Jul 2013 15:04:19 GMT

There are 8K external pull-ups on both SCL and SDA. The sensor recommends 1.5K - 20K. The Eval Kit board is USB powered and the sensor gets its power for an output pin.

Yes, the Softdevice is loaded. Is that an issue?

RE: TWI on nRF51822

Tielman — Tue, 02 Jul 2013 10:49:53 GMT

I notice that you initialize your twi master, but don't check to see if it was successful. Maybe just check that as well. I recently had a I2C device that caused the twi_master_init to fail if the device was not powered before the twi_master_init function was called. Probably not the issue, but still a good habit to check initialization before use.

RE: TWI on nRF51822

Marc Nicholas — Tue, 02 Jul 2013 10:28:25 GMT

Is it just me, or does your clock waveform appear to be upside down? Are you sure there's no polarity issue?

The waveform of the clock looks about right -- I'm not sure it's a pull-up issue personally, you would see more of a "saw tooth" waveform if you needed pull-ups IMHO. But I could be completely wrong, so give it a try with 4.7K (or anything you have between 1.5-10K).

Also, is it possible you have a clocking issue? I haven't finished my first pot of coffee yet, but on first look I didn't think you were generating a 400KHz clock...

Hopefully that might give you some other places to look :)

-m

RE: TWI on nRF51822

Tielman — Tue, 02 Jul 2013 10:06:01 GMT

The product specification for the NRF51822 actually specifies the RPU (pull-up resistance) for the GPIO to be about 13k (page 48 of PS v1.3).

Tom, I do agree with Philip though that 13k might not be enough for many devices and I also typically use 4.7k. I Still suggest that you try external pull-ups and see if you cant get your comms working. If it doesn't work, then we can dig further.

RE: TWI on nRF51822

Philip Freidin — Tue, 02 Jul 2013 08:44:58 GMT

Hi Tom,

It looks like you are relying on the pullup resistors in the nRF51822 for the TWI interface.

I searched the nRF51822 data sheet and could find nothing about the actual pullup resistor value :( See Tielman's reply to my post, I should have been looking in the Product Spec, not the Reference Manual

In my experience, these values tend to be any where from 10K to 200K in other products. When I design TWI (I2C) interfaces, I typically use 4.7K . If the pullup resistor is too high a resistance (which may be true in your case), then the rising edges on SDA and SCL can be too slow, and it may not rise to a valid logic high. You SDA_SDL_2.jpg picture certainly suggests this.

If your devices have different power rails, such as 2.5 V for one device and 3.0 for the other, the pull up resistors should connect to the higher rail. This won't work if there is significant difference (2.5V and 5V), in which case you need a level shifter as well as the pullup resistors.

Cheers, Philip

RE: TWI on nRF51822

Tielman — Tue, 02 Jul 2013 03:07:53 GMT

Hi Tom

Have you by any chance got the Softdevice loaded onto your device?

RE: TWI on nRF51822

Tom — Mon, 01 Jul 2013 21:46:18 GMT

Attached are the latest waveforms and revised code showing port initialization. I found a wiring error to the sensor (no power) but still is not working. Apparently the TX is not completing because it always exits the following command in twi_master_write() with timeout = 0. Five CLK's are issued but no SDA.

while(NRF_TWI1->EVENTS_TXDSENT == 0 && (--timeout)); // HANGING HERE (TIMEOUT ALWAYS 0)

twi.txt

RE: TWI on nRF51822

Tielman — Mon, 01 Jul 2013 06:20:32 GMT

Hi Tom

What is the supply to your system? From the graphs you sent, the SDA line goes to about 2.4V while the CLK only rises to about 1.3V. According to the datasheet of your TWI device, you need a supply of at least 2.6V and that comms should go up to 2.5V. Comms will definitely not work. Will you also send the pin configuration of your TWI lines? I do not see them in the code. Please note that according to Figure 15 in the nrf51822 Ref Manual, it appears that the pull configuration is only used when the pin has the input buffer enabled. Not sure if the pull-up is used when configured as output? Have you connected two external resistors to your comms lines to see if you can at least get comms to work to your device first? Maybe give this a try if you have not yet.

RE: TWI on nRF51822

Marc Nicholas — Sat, 29 Jun 2013 19:16:03 GMT

I can see the problem: your waveforms look exactly like the nRF51822 data sheet!

(I think you attached the wrong file...)

-m

RE: TWI on nRF51822

Tom — Sat, 29 Jun 2013 18:44:38 GMT

Attached are the SCL (yellow) and SDA (blue) waveforms. The difference between the 3 traces is the timebase.

After starting SCL runs continuously. SDA looks completely wrong so there is something major wrong. The slow risetime of SDA implies there may not be a pullup but I have enabled the on-chip pullups (none external) for SCL and SDA. I appears that both SCL and SDA go low nearly simultaneously (much less than 20ns apart).

I misunderstood youe question and uploaded the nRF51822 rather than the slave device. I thought that was an unusual request. :)

This forum is very particular about what file types can be attached. I attached the waveforms in BMP format and apparently they are not allowed. Here they are after converting to JPG.

MLX90325.pdf

RE: TWI on nRF51822

Marc Nicholas — Sat, 29 Jun 2013 13:54:51 GMT

Hi Tom,

Are you able to share the datasheet of the device you're working with?

Also, it sounds like you have a logic analyzer hooked-up (which is a Good Thing(tm)) -- are you seeing SCL go low after SDA goes low? i.e. an I2C/TWI start sequence?

The timing and pattern is important, so you'll want to capture both synchronously if you can.

See the attached image URL for details.

I'll go through your code, but I'm also experimenting with I2C, so may not be much help :p

Cheers,

-m