I2C write to Amis 30624 motor from Atsame54p20a in Atmel Studio

Question

I have been trying to write to the amis 30624 stepper motor (http://www.onsemi.com/pub/Collateral/AMIS-30624-D.PDF) using I2C protocol but for some reason its giving me Receive not acknowledge error. I have followed all the steps of I2C protocol mentioned in the asf4 documentation(http://ww1.microchip.com/downloads/en/DeviceDoc/50002633A.pdf) but in vain. Can someone please help me? Here is my I2c Write function:

void I2C_Write(uint8_t address_reg)
{
    gpio_set_pin_pull_mode(SDA,GPIO_PULL_OFF);
    struct io_descriptor *Asynch_master_io;
    i2c_m_async_get_io_descriptor(&Asynch_master, &Asynch_master_io);
    i2c_m_async_enable(&Asynch_master);
    i2c_m_async_register_callback(&Asynch_master, I2C_M_ASYNC_TX_COMPLETE, 
                                  (FUNC_PTR)Asynch_master_tx_complete);
    i2c_m_async_set_slaveaddr(&Asynch_master, 0x60,I2C_M_SEVEN);
    uint8_t var = address_reg;
    Asynch_master_example_str[0] = var;
    io_write(Asynch_master_io, Asynch_master_example_str,1);
    i2c_m_async_send_stop(&Asynch_master);  
}

The SDA and SCL have been pulled up in the initialization. SERCOM3 is used. SDA is pulled down in I2C start.

Answer 1

Update:

Following the plan in my original answer below, will lead you to a solution. However I just realised something which can be inferred from a statement in your question, and which could suggest a potential problem more quickly:

The SDA and SCL have been pulled up in the initialization.

Based on that statement, I suspect you are using the built-in pull-up resistors in the ATSAME54 MCU, since external pull-ups would not be initialised in code.

The current SAM E5x family datasheet states that the internal pull-ups will be between 20kΩ and 60kΩ, typically 40kΩ. From experience, that value range is too high for reliable I2C bus operation, except for the slowest, shortest buses.

Checking the I2C signal waveforms with an oscilloscope, as mentioned in my full answer, would allow you to check whether or not you have an issue in this area. However I would be surprised if using the internal pull-ups is not at least part of your problem(s).

If you don't have an oscilloscope, you could re-test after calculating and adding suitable external pull-up resistors to the I2C signals. However, there might be multiple problems e.g. you might fix one problem (replacing the use of internal pull-up resistors, with suitable external pull-up resistors) and still not be successful. In that case, you cannot assume that the original use of internal pull-up resistors wasn't a problem.

---

Original answer:

I haven't used that ASF4 software API / framework, but I'll tell you how I would approach this, if I was in your situation.

You need to see what is really happening on the I2C bus, to understand exactly what your I2C master code is sending and what (if anything) the I2C Slave is doing. Although you are getting a return code, many times I've seen return codes which don't accurately specify the problem, and they can be better viewed as saying simply "something went wrong".

If you are not 100% confident of the electrical validity of the I2C bus, then use an oscilloscope to view the analog signal characteristics e.g. voltage levels, rise/fall times, crosstalk between the signals etc.

After you are confident that the I2C bus is electrically OK, then you can use a logic analyser or equivalent (e.g. MSO), or even a standard oscilloscope again, to view and decode the I2C protocol to better understand what is happening at that level. (Cheap logic analysers capable of I2C decoding, although they have limitations, can be bought for only a few dollars and can be used with open-source Sigrok software.)

Compare the activity which you see on the I2C bus with what should happen, as shown in the I2C specification and in the documentation for that specific I2C Slave (some behaviour can vary between different I2C Slaves and is not fixed in the I2C specification alone).

That way, you can find where the I2C bus first deviates from expected behaviour, and you can focus on the h/w or s/w responsible for that specific part.