Hot!PIC32MZ I2C delay

Page: 12 > Showing page 1 of 2
Author
nich2011
New Member
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2018/03/05 18:24:51
  • Location: 0
  • Status: offline
2018/09/13 19:37:23 (permalink)
0

PIC32MZ I2C delay

Hi there,
 
I paired up PIC32MZ EC starter kit as an I2C slave with another master. I observed correct transactions from master on SDA and SCL and then the slave replied. However, the slave only responds after I issue the same instruction on the second time. What could go wrong here?
Using Hamorny 2.06
 
void APP_Slave_Transfer_Callback( DRV_I2C_BUFFER_EVENT event, void * context )
{
    switch (event)
    {
        // Master must send two write transactions for it to take effect
        // Master sends data to slave I2C1
        case DRV_I2C_BUFFER_SLAVE_READ_REQUESTED:
        {
           i2c_id_1_buffer_handle = DRV_I2C_Receive( i2c_id_1_handle, thisDeviceAddress, &i2c_id_1_RxBuffer, i2c_id_1_BytesToRead, NULL );
            instruction = i2c_id_1_RxBuffer[0];
            if (instruction == 0b11110000)
            {
                BSP_LEDToggle(BSP_LED_1);
            }
            
            break;
        }
        
        // Master requests data from slave I2C1
        case DRV_I2C_BUFFER_SLAVE_WRITE_REQUESTED:
        {
            if (instruction == 0b11110000)
            {
                i2c_id_1_TxBuffer[0] = 0b11001100; // data
                i2c_id_1_BytesToWrite = 1;
                i2c_id_1_buffer_handle = DRV_I2C_Transmit ( i2c_id_1_handle, thisDeviceAddress, i2c_id_1_TxBuffer, i2c_id_1_BytesToWrite, NULL );
            }
            else if (i2c_id_1_RxBuffer[4] == 0b11110000)
            {
                i2c_id_1_TxBuffer[0] = 0b00001111; // data
                i2c_id_1_BytesToWrite = 1;
                i2c_id_1_buffer_handle = DRV_I2C_Transmit ( i2c_id_1_handle, thisDeviceAddress, i2c_id_1_TxBuffer, i2c_id_1_BytesToWrite, NULL );
            }
            else
            {
                //appData.i2c_id_1_state = APP_I2C_ID_1_WAIT_FOR_COMPLETE;
                i2c_id_1_TxBuffer[0] = 0b00110011; // data
                i2c_id_1_TxBuffer[1] = 0b10101010; // data
                i2c_id_1_BytesToWrite = 2;
                i2c_id_1_buffer_handle = DRV_I2C_Transmit ( i2c_id_1_handle, thisDeviceAddress, i2c_id_1_TxBuffer, i2c_id_1_BytesToWrite, NULL );
                BSP_LEDToggle(BSP_LED_2);
            }
            break;
        }
        default:
        {
            break;
        }
    }
    return;
}

post edited by nich2011 - 2018/09/13 19:48:02
#1

20 Replies Related Threads

    muellernick
    Super Member
    • Total Posts : 454
    • Reward points : 0
    • Joined: 2015/01/06 23:58:23
    • Location: Germany
    • Status: online
    Re: PIC32MZ I2C delay 2018/09/17 05:31:15 (permalink)
    4 (1)
    DRV_I2C_Receive only starts the read command. You have to look at the buffer status until it is DRV_I2C_BUFFER_EVENT_COMPLETE.
    Only then, data is available and valid.
    There's an example in the Harmony docs. But you can't ignore the callback function.

    Nick
    #2
    nich2011
    New Member
    • Total Posts : 8
    • Reward points : 0
    • Joined: 2018/03/05 18:24:51
    • Location: 0
    • Status: offline
    Re: PIC32MZ I2C delay 2018/09/17 16:59:50 (permalink)
    0
    Did you mean this?

    post edited by nich2011 - 2018/09/17 17:02:45

    Attached Image(s)

    #3
    muellernick
    Super Member
    • Total Posts : 454
    • Reward points : 0
    • Joined: 2015/01/06 23:58:23
    • Location: Germany
    • Status: online
    Re: PIC32MZ I2C delay 2018/09/18 00:15:05 (permalink)
    0
    Yes, either this or poll the state of the I2C driver until you get an error or DRV_I2C_BUFFER_EVENT_COMPLETE.
    My personal preference is polling. I consider callback-functions for tasks like these ugly. YMMV.
     
    All the Harmony drivers are state machines. You have to give them processing time.
    DRV_I2C_Receive etc. are not blocking.
    #4
    nich2011
    New Member
    • Total Posts : 8
    • Reward points : 0
    • Joined: 2018/03/05 18:24:51
    • Location: 0
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/07 17:41:01 (permalink)
    0
    Hi Nick,
     
    I tried polling polling the state of the driver after DRV_I2C_BUFFER_SLAVE_READ_REQUESTED.
    It shows that it is always stuck at DRV_I2C_BUFFER_SLAVE_READ_BYTE. It can never reach DRV_I2C_BUFFER_EVENT_COMPLETE unlike my other master code.
    post edited by nich2011 - 2018/10/07 19:10:56
    #5
    Paul PortSol
    Super Member
    • Total Posts : 333
    • Reward points : 0
    • Joined: 2015/07/03 11:52:03
    • Location: 0
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/10 05:14:31 (permalink)
    0
    Note the PIC32MZ Errata for I2C, hope you have the "bit bang implementation" selected in MHC I2C Driver.
    #6
    nich2011
    New Member
    • Total Posts : 8
    • Reward points : 0
    • Joined: 2018/03/05 18:24:51
    • Location: 0
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/10 18:51:31 (permalink)
    0
    I tried both module reset and bit bang options. After my master transmit address + 1 byte of data to my I2C slave, it ACK instead of NACK the data byte. Is this correct?
    #7
    qhb
    Superb Member
    • Total Posts : 7914
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/10 18:55:20 (permalink)
    0
    A slave should always ACK every data byte it receives.
    Is that what you are asking?
     
    A Master having to send NAK for the last data byte it wants to read is a totally different matter.
    #8
    nich2011
    New Member
    • Total Posts : 8
    • Reward points : 0
    • Joined: 2018/03/05 18:24:51
    • Location: 0
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/10 19:01:24 (permalink)
    0
    Well, it's master writing to my PIC but I am not sure whether my slave PIC should ACK or NACK the last byte.
    #9
    qhb
    Superb Member
    • Total Posts : 7914
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/10 19:05:22 (permalink)
    0
    nich2011
    ... I am not sure whether my slave PIC should ACK or NACK the last byte.

    I just told you.
    A slave should always ACK every byte.
     
    #10
    NKurzman
    A Guy on the Net
    • Total Posts : 16665
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/10 19:06:47 (permalink)
    0
    It should ACK the Address and the Data Byte.
    #11
    nich2011
    New Member
    • Total Posts : 8
    • Reward points : 0
    • Joined: 2018/03/05 18:24:51
    • Location: 0
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/10 19:07:28 (permalink)
    0
    https://imgur.com/a/KupoEXC
    I am confused. It is shown as NACK in the documentation
    post edited by nich2011 - 2018/10/10 19:09:15

    Attached Image(s)

    #12
    qhb
    Superb Member
    • Total Posts : 7914
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/10 19:09:58 (permalink)
    0
    -deleted.
    post edited by qhb - 2018/10/10 19:15:14
    #13
    nich2011
    New Member
    • Total Posts : 8
    • Reward points : 0
    • Joined: 2018/03/05 18:24:51
    • Location: 0
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/10 19:12:46 (permalink)
    0
    It was shown as NACK for the last data byte... Is there a way to know the number of incoming bytes for slave?
    post edited by nich2011 - 2018/10/10 19:17:33
    #14
    qhb
    Superb Member
    • Total Posts : 7914
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/10 19:17:02 (permalink)
    0
    nich2011
    https://imgur.com/a/KupoEXC
    I am confused. It is shown as NACK in the documentation

    That is for a read (where it is the Master outputting an ACK or a NAK).
    You are talking about a write (where the slave sends an ACK or NAK).
    Totally different situations.
     
    post edited by qhb - 2018/10/10 19:20:04
    #15
    qhb
    Superb Member
    • Total Posts : 7914
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/10 19:21:30 (permalink)
    0
    nich2011
    Is there a way to know the number of incoming bytes for slave?

    No. The Slave must accept all bytes sent by a Master. It can just discard any it doesn't want.
     
    Of course, if you control both the Master and the Slave, then you can define a protocol where you packetise the data, and include a packet length at the start.
     
     
    #16
    nich2011
    New Member
    • Total Posts : 8
    • Reward points : 0
    • Joined: 2018/03/05 18:24:51
    • Location: 0
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/10 20:25:20 (permalink)
    0
    OK. I get it now.
    Back to my original problem, I modified my complete I2C transaction to be a write + read packets. It cannot  be a single write packet. Time consuming operation to be performed at the start of read packet and then results are transmitted back to master. The master will NACK at the end of read. No more delay for any instruction that I wanted it to perform. Using module reset for errata fix.
    #17
    laffelt
    Super Member
    • Total Posts : 132
    • Reward points : 0
    • Joined: 2008/05/08 18:05:53
    • Location: 0
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/12 07:33:57 (permalink)
    0
    Question for Paul PortSol and others:
     
    What does the "bit-bang" configuration in MHC solve as pertaining to the errata? I am having an issue with the I2C port in my PIC32MZ where it occaisionally does not send the 9th clock pulse for ACK/NACK from the slave which causes the slave to hold the SDA line low waiting for it, so I have to turn the port off and bit-bang the clock pulse.

    Does changing to the bit-bank mode stop this from happening?
    If I change the I2C mode what changes are required in my code?
     
    Thanks in advance!
     
    Larry
    #18
    Paul PortSol
    Super Member
    • Total Posts : 333
    • Reward points : 0
    • Joined: 2015/07/03 11:52:03
    • Location: 0
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/12 08:00:51 (permalink)
    0
    Bit Bang option causes driver to be implemented in code instead of I2C module (you don't change anything else in MHC or code, leave pins assigned as I2C Clock and Data).
    It works. Details in the PIC's errata doc.
    Paul
    #19
    Aaron Hancock
    Junior Member
    • Total Posts : 87
    • Reward points : 0
    • Joined: 2016/02/23 15:10:25
    • Location: Virginia, USA
    • Status: offline
    Re: PIC32MZ I2C delay 2018/10/17 07:39:30 (permalink)
    0
    I gave up on the Harmony I2C and SPI drivers and wrote my own bit bang implementation.  I use timer delays to control the clock speed.  Not the most CPU time efficient way of doing things, but it is hard to argue with something that works.
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2018 APG vNext Commercial Version 4.5