PSoC Freezes during I2C Transmit with no Slave

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
xahuc_3536641
Level 2
Level 2

Hi All,

I have seen a lot of posts about I2C transmission issues, but none that seem to help point me in the right direction.

I have an issue where every time I try to send a message to a slave that doesn't exist on the bus, the whole PSoC freezes up! I can trigger it at will and using the debugger I have found it gets stuck in the while loop on line 29 of the following chunk of generated code:

uint8 I2C_Master_MasterSendStart(uint8 slaveAddress, uint8 R_nW)
     
{
    uint8 errStatus;

    errStatus = I2C_Master_MSTR_NOT_READY;

    /* If IDLE, check if bus is free */
    if(I2C_Master_SM_IDLE == I2C_Master_state)
    {
        /* If bus is free, generate Start condition */
        if(I2C_Master_CHECK_BUS_FREE(I2C_Master_MCSR_REG))
        {
            /* Disable interrupt for manual master operation */
            I2C_Master_DisableInt();

            /* Set address and read/write flag */
            slaveAddress = (uint8) (slaveAddress << I2C_Master_SLAVE_ADDR_SHIFT);
            if(0u != R_nW)
            {
                slaveAddress |= I2C_Master_READ_FLAG;
                I2C_Master_state = I2C_Master_SM_MSTR_RD_ADDR;
            }
            else
            {
                I2C_Master_state = I2C_Master_SM_MSTR_WR_ADDR;
            }

            /* Hardware actions: write address and generate Start */
            I2C_Master_DATA_REG = slaveAddress;
            I2C_Master_GENERATE_START_MANUAL;

            /* Wait until address is transferred */
            while(I2C_Master_WAIT_BYTE_COMPLETE(I2C_Master_CSR_REG))
            {
            }

        #if(I2C_Master_MODE_MULTI_MASTER_SLAVE_ENABLED)
            if(I2C_Master_CHECK_START_GEN(I2C_Master_MCSR_REG))
            {
                I2C_Master_CLEAR_START_GEN;

                /* Start condition was not generated: reset FSM to IDLE */
                I2C_Master_state = I2C_Master_SM_IDLE;
                errStatus = I2C_Master_MSTR_ERR_ABORT_START_GEN;
            }
            else
        #endif /* (I2C_Master_MODE_MULTI_MASTER_SLAVE_ENABLED) */

        #if(I2C_Master_MODE_MULTI_MASTER_ENABLED)
            if(I2C_Master_CHECK_LOST_ARB(I2C_Master_CSR_REG))
            {
                I2C_Master_BUS_RELEASE_MANUAL;

                /* Master lost arbitrage: reset FSM to IDLE */
                I2C_Master_state = I2C_Master_SM_IDLE;
                errStatus = I2C_Master_MSTR_ERR_ARB_LOST;
            }
            else
        #endif /* (I2C_Master_MODE_MULTI_MASTER_ENABLED) */

            if(I2C_Master_CHECK_ADDR_NAK(I2C_Master_CSR_REG))
            {
                /* Address has been NACKed: reset FSM to IDLE */
                I2C_Master_state = I2C_Master_SM_IDLE;
                errStatus = I2C_Master_MSTR_ERR_LB_NAK;
            }
            else
            {
                /* Start was sent without errors */
                errStatus = I2C_Master_MSTR_NO_ERROR;
            }
        }
        else
        {
            errStatus = I2C_Master_MSTR_BUS_BUSY;
        }
    }

    return(errStatus);
}

Now I know for sure that if the I2C master tries to communicate with a slave that isn't present, it shouldn't cause the bus to fail. I have NO idea why it is and it's causing me serious problems because of the intended application.

Below is a copy of my I2C code:

#include "project.h"
#include "I2C.h"

void I2C_Delay();
void I2C_Reset();

uint8 I2C_Start()
{
    I2C_Master_Start();
    return I2C_SUCCESS;
}

void Clear_Read_Buff(uint8* data, uint8 data_length)
{
    for(uint8 i = 0; i < data_length; i++)
    {
        data = 0;
    }
}

uint8 I2C_Master_Write_Data(uint8 slave_address, uint8* data, uint8 data_length)
{
    uint8 status = 0;
   
    status = I2C_Master_MasterSendStart(slave_address, I2C_Master_WRITE_XFER_MODE);
    if(status == I2C_Master_MSTR_NO_ERROR)
    {
        for(uint8 i = 0; i < data_length; i++)
        {
            status = I2C_Master_MasterWriteByte(data);
            if(status != I2C_Master_MSTR_NO_ERROR)
            {
                I2C_Master_MasterSendStop();
                I2C_Delay();
                I2C_Reset();
                return I2C_FAILURE;
            }
        }
    }
    else
    {               
        I2C_Master_MasterSendStop();
        I2C_Delay();
        I2C_Reset();
        return I2C_FAILURE;
    }
    I2C_Master_MasterSendStop();
    I2C_Delay();
    return I2C_SUCCESS;
}

uint8 I2C_Master_Read_Data(uint8 slave_address, uint8 mem_loc, uint8* data_buf, uint8 data_length)
{   
    uint8 status = 0;
   
    status = I2C_Master_MasterSendStart(slave_address, I2C_Master_WRITE_XFER_MODE);
    if(status == I2C_Master_MSTR_NO_ERROR)
    {
        status = I2C_Master_MasterWriteByte(mem_loc);
        if (status != I2C_Master_MSTR_NO_ERROR)
        {
            I2C_Master_MasterSendStop();
            I2C_Delay();
            I2C_Reset();
            return I2C_FAILURE;
        }
    }
    else
    {
        I2C_Master_MasterSendStop();
        I2C_Delay();
        I2C_Reset();
        return I2C_FAILURE;
    }
   
    status = I2C_Master_MasterSendRestart(slave_address, I2C_Master_READ_XFER_MODE);
    if(status == I2C_Master_MSTR_NO_ERROR)
    {
        for(uint8 i = 0; i < data_length - 1; i++)
        {
            data_buf = I2C_Master_MasterReadByte(I2C_Master_ACK_DATA);
        }
        data_buf[data_length - 1] = I2C_Master_MasterReadByte(I2C_Master_NAK_DATA);
    }
    else
    {
        I2C_Master_MasterSendStop();
        I2C_Delay();
        I2C_Reset();
        return I2C_FAILURE;
    }
    I2C_Master_MasterSendStop();
    I2C_Delay();
    return I2C_SUCCESS;
}

/* I2C Read with a 16 Byte Memory Location */
uint8 I2C_Master_Read_Data16(uint8 slave_address, uint16 mem_loc, uint8* data_buf, uint8 data_length)
{   
    uint8 status = 0;
    uint8 mem_loc_h = (mem_loc & 0xFF00) >> 8;
    uint8 mem_loc_l = (mem_loc & 0x00FF);
   
    status = I2C_Master_MasterSendStart(slave_address, I2C_Master_WRITE_XFER_MODE);
    if(status == I2C_Master_MSTR_NO_ERROR)
    {
        status = I2C_Master_MasterWriteByte(mem_loc_h);
        if(status == I2C_Master_MSTR_NO_ERROR)
        {
            status = I2C_Master_MasterWriteByte(mem_loc_l);
            if (status != I2C_Master_MSTR_NO_ERROR)
            {
                I2C_Master_MasterSendStop();
                I2C_Delay();
                I2C_Reset();
                return I2C_FAILURE;
            }
        }
    }
    else
    {
        I2C_Master_MasterSendStop();
        I2C_Delay();
        I2C_Reset();
        return I2C_FAILURE;
    }
   
    status = I2C_Master_MasterSendRestart(slave_address, I2C_Master_READ_XFER_MODE);
    if(status == I2C_Master_MSTR_NO_ERROR)
    {
        for(uint8 i = 0; i < data_length - 1; i++)
        {
            data_buf = I2C_Master_MasterReadByte(I2C_Master_ACK_DATA);
        }
        data_buf[data_length - 1] = I2C_Master_MasterReadByte(I2C_Master_NAK_DATA);
    }
    else
    {
        I2C_Master_MasterSendStop();
        I2C_Delay();
        I2C_Reset();
        return I2C_FAILURE;
    }
    I2C_Master_MasterSendStop();
    I2C_Delay();
    return I2C_SUCCESS;
}

uint8 I2C_Master_Read_Byte(uint8 slave_address, uint8* result)
{
    uint8 status = 0;

    status = I2C_Master_MasterSendStart(slave_address, I2C_Master_READ_XFER_MODE);
    if(status == I2C_Master_MSTR_NO_ERROR)
    {
        *result = I2C_Master_MasterReadByte(I2C_Master_ACK_DATA);
    }
    else
    {
        I2C_Master_MasterSendStop();
        I2C_Delay();
        I2C_Reset();
        return I2C_FAILURE;
    }
   
    I2C_Master_MasterSendStop();
    I2C_Delay();
    return I2C_SUCCESS;
}

void I2C_Delay()
{
    CyDelay(I2C_DELAY_MS);
}

void I2C_Reset()
{
    I2C_Reset_Reg_Write(0b1);
    I2C_Master_Stop();
    I2C_Master_Start();
   
//    Indicator_LED_OUT_Write(0x00);
//    CyDelay(50);
//    Indicator_LED_OUT_Write(0x01);
//    CyDelay(50);
//    Indicator_LED_OUT_Write(0x00);
//    CyDelay(50);
//    Indicator_LED_OUT_Write(0x01);
//    CyDelay(50);
//    Indicator_LED_OUT_Write(0x00);
}

Any and all help is appreciated! I have no idea what I am doing wrong.

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.

Hi xavier.hubbard_3536641​,

Thanks for the update. From the images you have sent, it is like the master is trying to send a start condition but something is pulling the line high. There could be timing issues in the communication due to parasitic capacitance and selection of pull up resistors. But if that is the case, this issue should have occurred under normal conditions also.

But if the issue is with the PSoC firmware, then this issue should have occurred even with the slave present. Anyhow since it is a low level API, it has many blocking while loops without any timeout features. I have attached a sample code wherein I have created a custom API CustomMasterSendStart() that has a timeout feature using SysTick timer in it. Please find the attached sample project and let me know if it resolves your issue.

Under ideal conditions, the PSoC master should just receive a NACK if there is no slave (that is addressed by master) in the bus.

Under no circumstance I could replicate your issue. The one and only time it occurred was when the I2C bus was disturbed. (Disconnected master from bus)

Now since I couldn't replicate your issue, I want you to try a very simple I2C Low level API sample code with anyone of your slave device. If you still face the issue, there is problem with the PSoC device. If not, there is something else wrong in your hardware/ other part of your firmware.

Could you please try the following also?

1.Try using high level APIs and see if you still face the issue.

2. Before checking for the  while(I2C_Master_WAIT_BYTE_COMPLETE(I2C_Master_CSR_REG)) , check if the start condition generation is complete by checking the start_gen bit of  I2C_MCSR register. Check if it has become 0. It becomes 0 when start condition generation is complete. I hope this will always be 1 in your case.  Since no start condition was generated, byte_complete bit of I2C_CSR register will never be set to 1. (Data have been transmitted and an ACK or NACK has been received.) This is what we are checking in the while loop.

Also what is the data rate and the pull up resistors value you are using. Can you check the following?

1. Decrease data rate and report the no of times this failure occurs

2. Increase data rate and report the no of times the failure occurs.

Regards,

Bragadeesh

Regards,
Bragadeesh

View solution in original post

0 Likes
23 Replies
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi xavier.hubbard_3536641​,

Could you please share your project file so that I can try to reproduce your issue and find the solution for your problem.

Is it possible for you to place some sort of a timeout feature or watchdog timer that would reset your PSoC if it expires?

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

Hi BragadeeshV_41​,

I  would prefer not to attach the entire project as it has some proprietary work information in it and it would be quite time intensive to strip it out. Additionally, the PSoC is designed to act as a slave converting MODBUS commands over UART to I2C macros, so you'd probably have to add quite a bit of code to get it up and running on your end. If you really think that this is the only way to do the debugging, I will strip out the necessary code and make the project something that could run on your end without editing.

I was hoping that the copy-pasted code above would be enough. It is everything relevant to the I2C communication aside from the header file.

0 Likes

Hi xavier.hubbard_3536641​,

I used your code to create a project, filling the gaps. Your code worked well when there was slave in the bus. Your code still worked fine when I disabled the slave device (master still connected to the bus). But when I disconnected the master from the bus, the PSoC got stuck in the while loop that you mentioned.

I believe that the same is happening at your end too. When you mean that the slave is removed, does that mean the I2C bus is not in pulled up state? Can you try connecting the master to the bus (pulled up to VDD) and try to replicate this issue?  I expect that your code shouldn't get stuck in any while loops then.

If at all there comes a situation wherein you need to disconnect the PSoC pins from I2C bus, stop the component first and then remove it from the bus.

Regards,

Bragadeesh

Regards,
Bragadeesh

Hi BragadeeshV_41​, thanks for taking the time to fill in the code yourself! I appreciate it very much.

So, my system is fairly simple. I have a central controller that is a PSoC, that controls several peripherals via I2C. The first set of these are color sensors that are controlled through an I2C mux:

pastedImage_0.png

I have one special i2c component that is removable from the system. It is connected via a hotswappable i2c buffer, TI TCA4311ADGKR. It is key that I remove and replace this component without powercycling the board. I get the freezing issue when I send an I2C message to this specific component and the component itself isn't present on the bus. I will try sending I2C messages to random addresses that I know aren't present and see if that recreates the issue or if it's specific to this particular part of the circuit. That should at least tell me if it is a hardware or firmware problem I think.

The PSoC schematic looks like this:

pastedImage_1.png

as you can see, there are already pull-ups on the board.

0 Likes

BragadeeshV_41​ Here's some more info from my experiments today.

First, I made sure that the failure happens no matter what address I use. Seems obvious, but I wanted to check. Writing to 0x00 fails just as much as 0x6C. Great.

Second, I noticed that if I add delays in certain places I can increase the likelihood of success, but not fully prevent failure. For example, some of the macro commands I am executing send several I2C commands to the address of the absent slave in a row. Typically this is a guaranteed  way to initiate the I2C bus lockup, always getting stuck in the while loop I mentioned above. However, if I step through them one at a time using the debugger, I can avoid the error more often than not. I also found that if I added a 10ms delay after each individual I2C command can help with increasing odds of success, but it DOES NOT fully prevent it. It just takes more tries to get it to fail after a single message.

Third, I was probing the I2C lines to see if they could give me any info. I set my scope to trigger on any i2c message addressed to the absent slave (0x6C). I noticed that there was a little blip on the I2C SDA line every time it failed. On the times it succeeded the blip was absent. Every time it failed the blip was present. I took two useful images from the scope. The first shows a single I2C message attempted and failing with the noticeable trailing dip on the SDA line. The second shows first a successful message with no blip followed by a failed message with a blip. The second situation occurs far more often. Getting a single message to fail took many tries. For reference, the red exclamation mark on the bus lines indicates that the address wasn't acknowledged.

Image 1:

pastedImage_0.png

Image 2:

pastedImage_1.png

I haven't seen this issue before. I am at a bit of a loss as to what's going on. Any and all help is appreciated.

0 Likes

BragadeeshV_41

More info for you.

I chased the issue back to that single while loop and the actual generation of the start condition. I have found that the addition of a 1ms delay on line 27 of the snippet below alleviates the problem completely. Given that this code is generated, it is not a real solution, but can hopefully clue us in to the real solution down the road.

I have only copied the relevant portion of the code:

uint8 I2C_Master_MasterSendStart(uint8 slaveAddress, uint8 R_nW)
     
{
    uint8 errStatus;

    errStatus = I2C_Master_MSTR_NOT_READY;

    /* If IDLE, check if bus is free */
    if(I2C_Master_SM_IDLE == I2C_Master_state)
    {
        /* If bus is free, generate Start condition */
        if(I2C_Master_CHECK_BUS_FREE(I2C_Master_MCSR_REG))
        {
            /* Disable interrupt for manual master operation */
            I2C_Master_DisableInt();

            /* Set address and read/write flag */
            slaveAddress = (uint8) (slaveAddress << I2C_Master_SLAVE_ADDR_SHIFT);
            if(0u != R_nW)
            {
                slaveAddress |= I2C_Master_READ_FLAG;
                I2C_Master_state = I2C_Master_SM_MSTR_RD_ADDR;
            }
            else
            {
                I2C_Master_state = I2C_Master_SM_MSTR_WR_ADDR;
            }

            /* Hardware actions: write address and generate Start */
            I2C_Master_DATA_REG = slaveAddress;
            CyDelay(1);
            I2C_Master_GENERATE_START_MANUAL;

            /* Wait until address is transferred */
            while(I2C_Master_WAIT_BYTE_COMPLETE(I2C_Master_CSR_REG))
            {
            }

The plot thickens.

0 Likes
lock attach
Attachments are accessible only for community members.

Hi xavier.hubbard_3536641​,

Thanks for the update. From the images you have sent, it is like the master is trying to send a start condition but something is pulling the line high. There could be timing issues in the communication due to parasitic capacitance and selection of pull up resistors. But if that is the case, this issue should have occurred under normal conditions also.

But if the issue is with the PSoC firmware, then this issue should have occurred even with the slave present. Anyhow since it is a low level API, it has many blocking while loops without any timeout features. I have attached a sample code wherein I have created a custom API CustomMasterSendStart() that has a timeout feature using SysTick timer in it. Please find the attached sample project and let me know if it resolves your issue.

Under ideal conditions, the PSoC master should just receive a NACK if there is no slave (that is addressed by master) in the bus.

Under no circumstance I could replicate your issue. The one and only time it occurred was when the I2C bus was disturbed. (Disconnected master from bus)

Now since I couldn't replicate your issue, I want you to try a very simple I2C Low level API sample code with anyone of your slave device. If you still face the issue, there is problem with the PSoC device. If not, there is something else wrong in your hardware/ other part of your firmware.

Could you please try the following also?

1.Try using high level APIs and see if you still face the issue.

2. Before checking for the  while(I2C_Master_WAIT_BYTE_COMPLETE(I2C_Master_CSR_REG)) , check if the start condition generation is complete by checking the start_gen bit of  I2C_MCSR register. Check if it has become 0. It becomes 0 when start condition generation is complete. I hope this will always be 1 in your case.  Since no start condition was generated, byte_complete bit of I2C_CSR register will never be set to 1. (Data have been transmitted and an ACK or NACK has been received.) This is what we are checking in the while loop.

Also what is the data rate and the pull up resistors value you are using. Can you check the following?

1. Decrease data rate and report the no of times this failure occurs

2. Increase data rate and report the no of times the failure occurs.

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

BragadeeshV_41​ Thank you. You are so immensely helpful.

So before implementing your CustomSendStart Function, I wanted to check the bus speeds to see if that was an issue as it seemed to me to be a very likely source of struggle.

The speed was originally 100kbps with 2k pull-ups. When slowing to 50kbps, I saw no errors. When increasing speed to 400kbps, error rate drastically increased. The 400kbps had different behavior and would sometimes drop out in the middle of packets.

Edit: I changed the speed to 75kbps and found that it still freezes (though less often), but the "blip" does not seem to occur.

I'm a bit surprised if this is the case as the edges on the SDA and SCL lines look fairly clean at 100kbps and you are only just starting to see the RC time constants on the edges at 400kbps. I'd also be pretty surprised if 2k pull-up resistors were too big... The bus IS fairly large I suppose, but... That goes a bit against my intuition.

I'll test your other suggestions shortly.

0 Likes

Hi xavier.hubbard_3536641​,

Thanks for the update!

Please refer to the NXP I2C Specifications, for choosing the correct pull up resistors based on your data rate, bus capacitance and VDD. These are the limiting factors here. In particular, refer to the Pull-up resistor sizing section from the document.

Let us know your results!

Happy to help!

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

BragadeeshV_41

I changed the Pull-up values to be 1k from 2k as a quick test and the issue persists, as I expected. I am already being pretty aggressive with 2k and the edges look very clean at 100kbps. This leads me to believe the issue lies elsewhere.

I will try the firmware fixes and post results here.

0 Likes

BragadeeshV_41

I'm a bit confused about the CustomMasterSendStart function you wrote.

/* Wait until address is transferred */

            while(I2C_Master_WAIT_BYTE_COMPLETE(I2C_Master_CSR_REG))

            {

               

                if(counter == timeout)

                {

                    counter = 0;

                    timeoutFlag = 1;

                    break;

                }

                else if (counter > timeout)

                {

                    counter = 0; 

                }

                else

                {

                    timeoutFlag = 0;

                }

               

            }

It looks like the intent here was to simply add a counter that will make the while loop timeout, but I can't find anything that actually increments the counter? How did you intend to do it?

And for reference, with this, as expected, still got caught in this while loop. It just never escapes haha.

Edit:

I added a counter++; to the last else block and it does successfully keep the I2C bus from locking up. I can still see the "blip" on the bus, but naturally it just breaks out of the loop. It's a bit weird and I still don't understand the fundamental source of the problem here.

0 Likes
lock attach
Attachments are accessible only for community members.

BragadeeshV_41

Using High Level APIs presents errors just as it used to. When I began development of the I2C code I started with the High-Level Macros (I2C_MasterWriteBuf(...), etc....). Here is an example of High-Level Macro use:

uint8 I2C_Master_Write_Data(uint8 slave_address, uint8* data, uint8 data_length)

{

    I2C_Master_MasterWriteBuf(slave_address, data, data_length, I2C_Master_MODE_COMPLETE_XFER);

    return I2C_SUCCESS;

}

I consistently ran into an issue where the PSoC would get stuck in a halt state here (line 10):

void CyHalt(uint8 reason) CYREENTRANT
{
    if(0u != reason)
    {
        /* To remove unreferenced local variable warning */
    }

    #if defined (__ARMCC_VERSION)
        __breakpoint(0x0);
    #elif defined(__GNUC__) || defined (__ICCARM__)
        __asm("    bkpt    1");
    #elif defined(__C51__)
        CYDEV_HALT_CPU;
    #endif  /* (__ARMCC_VERSION) */
}

I was never able to get to the bottom of this issue which is what motivated me moving to the lower level APIs in the first place. The weird thing about the High-Level APIs is that the failures do not happen all the time. In fact they are somewhat infrequent, showing up 1 in maybe every 100-500 messages that are sent. I initially debugged this by setting a loop to send the same I2C message over and over again with a delay in the middle. I'd get an error every 500 messages or so and the PSoC would get stuck in CyHalt with no way to exit.

Furthermore my low-level API implementation is largely the same as the one found here.​ I don't know what I am doing wrong

Edit: Completely motivated by desperation, I've attached my entire project. The MODBUS and Color Sensor stuff should be largely irrelevant, but again I am not certain. Maybe my TopDesign is the problem? I don't know anymore

0 Likes

Hi xavier.hubbard_3536641​,

I've incremented the counter in the SysTickISRCallback() in main.c . Basically I've implemented a systick timer that increments the counter every 1 ms.

void SysTickISRCallback(void)

{

counter++;

}

Give me some time to debug your project. Give get back soon

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

BragadeeshV_41

Sorry... I opened main.h yesterday and just didn't realize it wasn't main.c. Definitely experiencing some snowblindness there. My apologies.

Thanks for the assistance. I await your reply.

Also, are you a Cypress employee or just a very kind internet stranger?

0 Likes

Hi xavier.hubbard_3536641​,

Thank you for waiting. Finally I was able to reproduce your issue. In the I2C_Reset(), you have reset the block using    I2C_Reset_Reg_Write(0b1); This will reset the I2C block. But you have bring it back to 0 for I2C block to come out of reset. So modify your I2C_Reset() code to the following:

void I2C_Reset()

{

    I2C_Reset_Reg_Write(0b1);

    I2C_Master_Stop();

    I2C_Reset_Reg_Write(0b0);

    I2C_Master_Start();

}

But a mere stop and start would reset the component. Your code is working fine now

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

I believe that pin should be configured as a pulse, no? It should be ahtomatiautom resetting to 0.

0 Likes

Hi xavier.hubbard_3536641​,

The reset pin does a hardware reset to the component. When it's given a 1 the component is held at reset. You have to set it to 0 to bring it out of reset. Please refer to the component datasheet for more information

pastedImage_0.png

In this case you can use the High level APIs also.

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

Hi,

Yes, the I2C_Reset_Reg is configured in "pulse" mode, meaning it should write a 1 for a clock cycle and then a 0. Have I missed understood how that works?

0 Likes

Hi xavier.hubbard_3536641​,

I will check on that. Was your issue resolved when you tried my previous suggestion?

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

BragadeeshV_41

No the issue persists, but for now I am just using the custom_send_start as a bandaid until I find a longer term fix.

I also managed to get it stuck in the Send_Stop while loop, but I couldn't recreate it after many trials.

0 Likes

xavier.hubbard_3536641​,

Can you try the I2C using fixed function instead of UDB? In that you would not have the reset option and I believe your issue might get resolved.

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

BragadeeshV_41

I only switched to the UDB implementation BECAUSE it has a reset option. This problem initially showed up during the fixed function implementation.

However, I have since changed the hardware a little bit, so I can try it again, though I expect the same results.

0 Likes

Hi xavier.hubbard_3536641​,

First we need to figure out if this is a hardware issue or a firmware issue,

1. Remove all the slaves from the bus, have only the master, implement a very simple i2c code example using one of our available tested code examples and see if you can reproduce the issue. We expect that you shouldn't be able  to reproduce the issue.

2. Now add all the slaves in the bus, try the same basic code example and see if you're able to reproduce the issue. If you get the issue, then the issue is with the hardware setup.

3. Now don't have any slaves on the bus, but use your firmware and see if you're able to reproduce this issue. If you get the issue, then the issue is with the firmware.

4. At this step you should be able to figure out if it is a hardware or a firmware issue.

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes