TWI, Always get ANACK error?

[Mitch996]

Hi, when trying to read a register from a chip using the IIC interface,blocking mode:

uint32_t ms5837_cmd_read(uint8_t *data, uint8_t length, uint8_t register_address)
{
uint32_t err_code;
err_code = nrf_drv_twi_tx(&m_twi_ms_5837, MS5837_TWI_ADDR, &register_address ,  1, true);



if (NRF_SUCCESS == err_code)
	
   err_code = nrf_drv_twi_rx(&m_twi_ms_5837, MS5837_TWI_ADDR, data, length, false);
		
	
APP_ERROR_CHECK(err_code);
	return err_code;	
}			

I always get the "enternal error", 0x03.

I looked up the register and found this:

As you can see, there is an ANACK error, suggesting there isn't an ACK after address write.

What should I do to solve this???

Help!!!!

@endnode can you please provide a little insight?

[MartinBL]

It sounds like the nRF5 is not in contact with your slave. Have you double checked your wires, pinout, and that you are using the correct slave address? You should try the twi_scanner app in the SDK to see if you get any response on any of the TWI addresses at all infocenter.nordicsemi.com/.../twi_scanner_example.html

[Mitch996]

Hi, that's what I initially thought at first, but I have sent some commands prior to it, and on the oscilliscope, it does appear that it is responding. How did I know? The 9th digits of the i2c format are low, which indicates that the slave device is responding - unless of course something else is pulling the data wire low, which is very unlikely because A. I'm positive other devices are offline; B. the "low" came right after I sent the correct address.

The prior successful communication took place like this:

Master sends target device address - slave responds by pulling down at 9th clock signal -> Master sends target register address (reset) - slave responds by pulling down at 9th clock signal.

The above described is the resetting procedure, but when it comes to reading, everything seems to be in the dump. Based on your experience, what could be causing this unresponsiveness, after prior responsiveness?

[MartinBL]

I don't think I have seen anything like this before. Here is what i2c-bus.org suggests: www.i2c-bus.org/.../

Can you post some screenshots of the signals?

[Mitch996]

Hi, no problem: here you go:https://imgur.com/a/J6bT4

As you can see, the clock, after sending the cmd/target register address, stays low for some reason... based on my limited knowledge, it should go high, together with a high SDA, they make up the "stop condition".

Edit: Oh, this is the reset command. You can see that the first command was responded to properly, the 9th bit was a low.

Also after sending these 2 9 bit data, the ERROR SRC register is 0, suggesting everything went well.

And then if I try to read registers (the transaction above was a reset sequence, required to interact with this chip), I can send just fine, but when it comes to read, the slave will not respond at all after the slave device address (not register address, it was already sent prior to the read, you know, tx first, rx later). I'll see if I can capture that wave form too and post it here.

[Mitch996]

Follow up: Stranger things... I dunno if it was caused by the fact that the reset sequence was a failure, but after some delay, required by the datasheet of the slave device, and I try to read its register, the master, my nrf51822 that is, sends only target register in the first step/ TX - which prompts me to suspect that maybe nrf51822 think its a continuation of last transaction? Or in other words, I must manually code nrf51822 for it to know a session has ended, and at the same time, it sends the proper stop condition? Anyway, here's the tx wave, the first step of the 2 steps:

https://imgur.com/a/D0Nu9

And the errorcode is 0, which suggests it is successful. This is really weird but since the 9th bit was a low, it isn't all that weird?...