I2C write a buffer bug ? #661

amirc2013 · 2019-09-19T17:59:49Z

Im trying to send a buffer over a I2C communication.
this is the code i used :

 Wire.beginTransmission(SCREEN_WRITE_addr);
  Wire.write(addr);
  unsigned char* ptr = data;
  for (int i = 0 ; i < len ; i++) {
    Wire.write(*ptr);
     if (DEBUG) {
      Serial.print("WE WROTE :");
      Serial.println(*ptr,HEX);
    }
    ptr++;
  }
  Wire.endTransmission(true);

some how only the last byte has been sent ... why ?

The text was updated successfully, but these errors were encountered:

amirc2013 · 2019-09-19T20:59:30Z

it seems like it is depended on the size of what im sending ... so ... can anyone explain why ?

fpistm · 2019-09-20T06:57:59Z

Hi @amirc2013
could you be more precise about your issue as described in the GitHub issue template:
Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Complete source code which can be used to reproduce the issue. Please try to be as generic as possible (no extra code, extra hardware,...)

Desktop (please complete the following information):

OS: [e.g. Windows]
Arduino IDE version: [e.g. 1.8.8]
STM32 core version: [e.g. 1.4.0]
Tools menu settings if not the default: [e.g. Newlib Standard, No Serial]
Upload method: [e.g. STLink]

Board (please complete the following information):

Name: [e.g. Nucleo F429ZI]
Hardware Revision: [e.g. Rev B]
Extra hardware used if any: [e.g. X-Nucleo IKS01A1]

Additional context
Add any other context about the problem here.

Full sketch. Which I2C device you used. how it is wired. Do you use PULLUP resistors on the line...

fpistm · 2019-09-24T06:56:08Z

@amirc2013
without any feedback I will close this issue.

amirc2013 · 2019-09-24T07:48:44Z

Bug :
Can't write a big buffer to the i2c line. Seems like there is a limitation which I can't find where or why.

fpistm · 2019-09-24T08:13:45Z

@amirc2013
OK but you do not provide enough information.
Which board you used, which I2C hardware, how it is wired.
As said I could not help without more info.
I do not ask to close the issue, only to have more info to be able to help...

amirc2013 · 2019-09-24T08:35:38Z

I will send everything later when I come back home ok ? Thanks

…

On Tue, Sep 24, 2019, 11:13 Frederic Pillon ***@***.***> wrote: @amirc2013 <https://github.com/amirc2013> OK but you do not provide enough information. Which board you used, which I2C hardware, how it is wired. As said I could not help without more info. I do not ask to close the issue, only to have more info to be able to help... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#661?email_source=notifications&email_token=ACX2F4UVHRE2SNUOD5GHMYTQLHD4DA5CNFSM4IYOIVM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7NQAQA#issuecomment-534446144>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACX2F4S5MNJ7YDGMX3CQDJDQLHD4DANCNFSM4IYOIVMQ> .

fpistm · 2019-09-24T08:42:25Z

No worries ;)

ghost · 2019-09-24T21:07:32Z

I2C buffer is 32 bytes. Maybe that is the problem?

fpistm · 2019-09-25T05:50:08Z

Right by default I2C_BUFFER is 32 bytes but it is a dynamic allocated buffer which can growth if needed.
I ask about more info because if @amirc2013 used the GitHub repository then he could met an issue I've seen after repeated start feature introduction. For the 1.7.0, I've revert it.
So, while I do not get all info I could not help.

amirc2013 · 2019-09-25T10:15:28Z

Writing and uploading an answer right now. sorry for the delay ‫בתאריך יום ג׳, 24 בספט׳ 2019 ב-11:42 מאת ‪Frederic Pillon‬‏ <‪ notifications@github.com‬‏>:‬

…

No worries ;) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#661?email_source=notifications&email_token=ACX2F4SZX6FEXDHJJEJCPTLQLHHHXA5CNFSM4IYOIVM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7NSYDQ#issuecomment-534457358>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACX2F4U2KX3GSP3EQKTXGG3QLHHHXANCNFSM4IYOIVMQ> .

amirc2013 · 2019-09-25T10:26:47Z

This is the simple formation of the code Im using for writing to the I2C.

My Real Program is really big and it is not understandalbe
so for this issue I will just use this instead.

static inline void i2c_write(
unsigned short addr,
unsigned char *data,
unsigned short len)
{
Wire.beginTransmission(SLAVE_addr);
Wire.write(addr);
Wire.write((const uint8_t *)data,(size_t)len);
Wire.endTransmission(true);
}

The bug :
When I'm writing a big data to this function - I just cant see then on my logic analyzer.
Only when I cut them down to 0x1000/10 bytes I will be able to see them.
This is super weird. Cause I need to write in 0x1000 chunk size...

My board : Nucleo L4R5ZI
OS: Windows
Arduino IDE version: 1.8.10
STM32 core version: How can I check that ?
Tools menu settings if not the default. Newlib Nano (default)
Upload method: Mass storage

Hardware Revision:How can I check that ?

I don't use any extra pull-up resistors.. Only connect a micro-controller to my STM with level shifter in the middle.

fpistm · 2019-09-25T11:58:11Z

STM32 core version: How can I check that ?

How did you install it? Boards manager? Using git repo? Anyway you can check here:

Arduino_Core_STM32/cores/arduino/stm32/stm32_def.h

Lines 5 to 21 in fb57942

    
           /** 
        
            * @brief STM32 core version number 
        
            */ 
        
           #define STM32_CORE_VERSION_MAJOR    (0x01U) /*!< [31:24] major version */ 
        
           #define STM32_CORE_VERSION_MINOR    (0x07U) /*!< [23:16] minor version */ 
        
           #define STM32_CORE_VERSION_PATCH    (0x00U) /*!< [15:8]  patch version */ 
        
           /* 
        
            * Extra label for development: 
        
            * 0: official release 
        
            * [1-9]: release candidate 
        
            * F[0-9]: development 
        
            */ 
        
           #define STM32_CORE_VERSION_EXTRA    (0x00U) /*!< [7:0]  extra version */ 
        
           #define STM32_CORE_VERSION          ((STM32_CORE_VERSION_MAJOR << 24U)\ 
        
                                                   |(STM32_CORE_VERSION_MINOR << 16U)\ 
        
                                                   |(STM32_CORE_VERSION_PATCH << 8U )\ 
        
                                                   |(STM32_CORE_VERSION_EXTRA))

Hardware Revision:How can I check that ?
on the sticker you should have something like MB1312 X where X is is the revision, anyway this is not very important in our case.

I don't use any extra pull-up resistors.. Only connect a micro-controller to my STM with level shifter in the middle.

Could you be more precise about this? which microconttoller and level shifter? how are they wired.
I2C lines require PULL up so ensure to have them on your wiring.

amirc2013 · 2019-09-25T13:56:32Z

I installed it with Boards manager - yes

This is my version:

*/
#define STM32_CORE_VERSION_MAJOR (0x01U) /*!< [31:24] major version */
#define STM32_CORE_VERSION_MINOR (0x06U) /*!< [23:16] minor version */
#define STM32_CORE_VERSION_PATCH (0x01U) /*!< [15:8] patch version */
/*

About the wiring :

It is an enterprise micro-controller and I just can't say which one is it yet :/
I'm checking if I can communicate with it.

I don't have a resistors on the I2C but maybe on the board of the other micro-controller it has one ?
I checked my level shifter (Logic Level Converter) and it doest have any name on it.

I can put some resistor on the line but as I saw on the logic analyzer - all the other part of the i2c communication are working.

uzi18 · 2019-09-25T13:58:36Z

any photos or schematics?

amirc2013 · 2019-09-25T14:06:45Z

:(
I know it looks bad.

I just can't talk about the micro controller.

Just assume I extracted a controller from some enterprise device and I want to communicate with it.
Moreover, I just want to update its firmware.

amirc2013 · 2019-09-25T16:20:56Z

new update :
It works when i write 0x1000-3 .... and even 0x1000-1 (0xfff)
WTF ?

maybe optimization ?

fpistm · 2019-09-26T14:12:31Z

I've found the issue.
Well, based on Arduino API it is not possible to handle more than 255 bytes as API based in uint8_t.
Anyway, I think there is a misalignment between HAL and Arduino layer.

amirc2013 · 2019-09-26T14:25:21Z

Well, I'm glad that I point the issue in the right place.
Thank you.
Waiting for updates :)

fpistm · 2019-09-26T14:40:01Z

I will try to see if I'm able to remove uint8_t date size limitations as HAL can handle uint16_t but I could not promise. In that case you would be able to send your 0x1000 in 16 times.

amirc2013 · 2019-09-26T14:41:14Z

I wish you luck, it is really important to me.
Thank you for the help :)

urosh-dev · 2019-11-08T11:05:57Z

Any updates on that. I have the same issue. I cant send string with Wire. for example Wire.write("hello");
Using blue pill and raspberry pi with command from raspberry pi :
bus.read_i2c_block_data(address,4)
or
bus.read_byte(address)
Blue pill just hangs up.

fpistm · 2019-11-08T12:08:42Z

Any updates on that. I have the same issue. I cant send string with Wire. for example Wire.write("hello");
Using blue pill and raspberry pi with command from raspberry pi :
bus.read_i2c_block_data(address,4)
or
bus.read_byte(address)
Blue pill just hangs up.

This is not related. Here the issue is for buffer higher than 32 in receive

fpistm · 2019-12-16T08:42:15Z

Current status:

Master:
- can write up to 255 (limited by Arduino API uint8_t)
- can read up to 32
Slave:
- can read/write up to 32

32 is the Arduino standard. The Master Tx has been extend to support the X-Shield NFC nevertheless
the Rx should be able to receive also 255 bytes. And Slave should be able to write also up to 255.

ABOSTM · 2020-01-03T17:09:23Z

Hi @amirc2013,
with implementation of PR #853, the status is 255 bytes transfer in any direction
(254 with the bug identified see warning).
But still limited by Arduino API uint8_t

fpistm added the waiting feedback Further information is required label Sep 20, 2019

amirc2013 closed this as completed Sep 24, 2019

fpistm reopened this Sep 24, 2019

fpistm self-assigned this Sep 26, 2019

fpistm added bug 🐛 Something isn't working on going Currently work on this and removed waiting feedback Further information is required labels Sep 26, 2019

fpistm added this to the 1.8.0 milestone Sep 26, 2019

fpistm removed the on going Currently work on this label Dec 16, 2019

fpistm removed this from the 1.8.0🎄 🎅 milestone Dec 16, 2019

fpistm assigned ABOSTM Dec 19, 2019

fpistm added this to the 1.9.0 milestone Dec 20, 2019

fpistm closed this as completed Jan 6, 2020

fpistm modified the milestones: 1.9.0, 1.8.1 Jan 6, 2020

fpistm modified the milestones: 1.8.1, 1.9.0 Jan 17, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

I2C write a buffer bug ? #661

I2C write a buffer bug ? #661

amirc2013 commented Sep 19, 2019 •

edited by fpistm

Loading

amirc2013 commented Sep 19, 2019

fpistm commented Sep 20, 2019

fpistm commented Sep 24, 2019

amirc2013 commented Sep 24, 2019

fpistm commented Sep 24, 2019

amirc2013 commented Sep 24, 2019 via email

fpistm commented Sep 24, 2019

ghost commented Sep 24, 2019

fpistm commented Sep 25, 2019

amirc2013 commented Sep 25, 2019 via email

amirc2013 commented Sep 25, 2019 •

edited

Loading

fpistm commented Sep 25, 2019

amirc2013 commented Sep 25, 2019

uzi18 commented Sep 25, 2019

amirc2013 commented Sep 25, 2019

amirc2013 commented Sep 25, 2019 •

edited

Loading

fpistm commented Sep 26, 2019

amirc2013 commented Sep 26, 2019

fpistm commented Sep 26, 2019

amirc2013 commented Sep 26, 2019

urosh-dev commented Nov 8, 2019

fpistm commented Nov 8, 2019

fpistm commented Dec 16, 2019

ABOSTM commented Jan 3, 2020

I2C write a buffer bug ? #661

I2C write a buffer bug ? #661

Comments

amirc2013 commented Sep 19, 2019 • edited by fpistm Loading

amirc2013 commented Sep 19, 2019

fpistm commented Sep 20, 2019

fpistm commented Sep 24, 2019

amirc2013 commented Sep 24, 2019

fpistm commented Sep 24, 2019

amirc2013 commented Sep 24, 2019 via email

fpistm commented Sep 24, 2019

ghost commented Sep 24, 2019

fpistm commented Sep 25, 2019

amirc2013 commented Sep 25, 2019 via email

amirc2013 commented Sep 25, 2019 • edited Loading

fpistm commented Sep 25, 2019

amirc2013 commented Sep 25, 2019

uzi18 commented Sep 25, 2019

amirc2013 commented Sep 25, 2019

amirc2013 commented Sep 25, 2019 • edited Loading

fpistm commented Sep 26, 2019

amirc2013 commented Sep 26, 2019

fpistm commented Sep 26, 2019

amirc2013 commented Sep 26, 2019

urosh-dev commented Nov 8, 2019

fpistm commented Nov 8, 2019

fpistm commented Dec 16, 2019

Current status:

ABOSTM commented Jan 3, 2020

amirc2013 commented Sep 19, 2019 •

edited by fpistm

Loading

amirc2013 commented Sep 25, 2019 •

edited

Loading

amirc2013 commented Sep 25, 2019 •

edited

Loading