i2c transfert reads one more byte than requested

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

cross mob
Anonymous
Not applicable

Hello.

I've found a bug in the i2c_transfer_message_no_dma function.

wiced 3.0.0, STM32F2, platform_i2c.c line 685.

The i2c transfert function reads one more byte than requested, making the cursor of my eeprom device I'm driving one byte ahead, making next sequencial read erroneous.

Existing code:

            if ( i == ( message->rx_length - 1 ) )
            {
                /* setup NACK for the last byte to be received */
                I2C_AcknowledgeConfig( i2c->port, DISABLE );
            }

Replace with:

           if(message->rx_length == 1) continue;


            if ( i == ( message->rx_length - 2 ) )
            {
                /* setup NACK for the last byte to be received */
                I2C_AcknowledgeConfig( i2c->port, DISABLE );
            }

0 Likes
11 Replies
Anonymous
Not applicable

Thanks!

0 Likes
Anonymous
Not applicable

May this fix be integrated in Wiced for next release ?

0 Likes

Hi,

Yes, we will integrate it to next release.

Seyhan

Anonymous
Not applicable

I am upgrading to Wiced 3.1.0, the bug is still there.

Here again the fix.

File:

          WICED/platform/MCU/STM32F2xx/peripherals/platform_i2c.c

Patch:

@@ -681,7 +681,8 @@

             /* get data */

             tmp_rd_ptr[ i ] = I2C_ReceiveData( i2c->port );

-            if ( i == ( message->rx_length - 1 ) )

+            if ( i == ( message->rx_length - 1 ) ) continue;   // xfer finished, will not re-enter the loop

+            if ( i == ( message->rx_length - 2 ) )             // IF WE ARE GOING TO READ THE LAST BYTE

             {

                 /* setup NACK for the last byte to be received */

                 I2C_AcknowledgeConfig( i2c->port, DISABLE );

@@ -789,7 +790,8 @@

                 /* get data */

                 tmp_ptr[ i ] = I2C_ReceiveData( i2c->port );

-                if ( i == ( message->rx_length - 1 ) )

+                if ( i == ( message->rx_length - 1 ) ) continue;       // xfer finished, will not re-enter the loop

+                if ( i == ( message->rx_length - 2 ) )         // IF WE ARE GOING TO READ THE LAST BYTE

                 {

                     /* setup NACK for the last byte to be received */

                     I2C_AcknowledgeConfig( i2c->port, DISABLE );

0 Likes
Anonymous
Not applicable

I am looking at the 3.1.1 code and I am not seeing this change.  Did it get missed?

0 Likes
Anonymous
Not applicable

So do I 😕

0 Likes
Anonymous
Not applicable

I just started another discussion to see why this fell through the cracks and how to create a bug report... maybe something here can change.

0 Likes

You bring up a good point.  We are using this Community Forum as a bug tracking system, but really it is not designed for that. Usually the issue is confirmed and converted to a bug in the Broadcom system, but this one may have been overlooked.  We are also going to have a separate space for Patches, Changes, and user generated "Sample code" so people can see what is available for use.

0 Likes
Anonymous
Not applicable

Maybe there needs to be a tag that is publicized as means of marking something as a possible bug.  Something that allows support at BRCM to quickly search through.  The amount of traffic can be overwhelming and in a lot of cases it is merely people needing a helping hand and not a problem in the BSP... Although it is always good to go through these also to see where BRCM can help make things clearer or add new samples, etc.

I hate to see the community taking their time to locate problems, show fixes and then have the problem drop through the cracks.  I already pinged Nik on another issue I found that was lurking about in the SPI code.  That one, I made sure, made it into JIRA but there has to be a way that is setup for others to be able to do the same thing without bothering the core engineers/managers.

Please come up with something.  This project is too important to not find a way to use the communities help in every way we can.

Anonymous
Not applicable

I can confirm that this fix is now in the development trunk and will be in the next release.

Anonymous
Not applicable

Thank you Nik

0 Likes