I’m trying to use HWire on I2C2 of my Bluepill to read/wire an external EEprom (24LC128).
I connected the EEprom on PB10 (SCL) and PB11 (SDA): if I use software version of I2C it works. If I use HWire it doesn’t work.
Bye the way: I downloaded last version of repository and I found an error on line 79 of Arduino_STM32/STM32F1/libraries/Wire/HardWire.cpp file: missing a “:” in void HardWire:end().
I used this code commenting the right lines (hardware or software I2C)… sorry for my bad engish:
//#include <Wire.h>
#include <HardWire.h>
#define EEPROM_ADDRESS 0x50 //Address of 24LC256 eeprom chip
//Declare the instance that the users of the library can use
//TwoWire Wire(SCL, SDA, SOFT_STANDARD);
//TwoWire Wire2(PB10, PB11, SOFT_STANDARD);
HardWire HWire(2, I2C_FAST_MODE); // I2C2
void setup(void)
{
Serial.begin(115200);
delay(10000);
Serial.println("EEPROM Test");
//Wire2.begin();
HWire.begin();
unsigned int address = 0;
writeEEPROM(EEPROM_ADDRESS, address, 0x55);
while(1){
Serial.print(readEEPROM(EEPROM_ADDRESS, address), HEX);
Serial.print(" ");
address++;
delay(1000);
}
}
void loop(){}
void writeEEPROM(int deviceaddress, unsigned int eeaddress, byte data )
{
// Wire2.beginTransmission(deviceaddress);
// Wire2.write((int)(eeaddress >> 8)); // MSB
// Wire2.write((int)(eeaddress & 0xFF)); // LSB
// Wire2.write(data);
// Wire2.endTransmission();
HWire.beginTransmission(deviceaddress);
HWire.write((int)(eeaddress >> 8)); // MSB
HWire.write((int)(eeaddress & 0xFF)); // LSB
HWire.write(data);
HWire.endTransmission();
delay(5);
}
byte readEEPROM(int deviceaddress, unsigned int eeaddress )
{
byte rdata = 0xFF;
// Wire2.beginTransmission(deviceaddress);
// Wire2.write((int)(eeaddress >> 8)); // MSB
// Wire2.write((int)(eeaddress & 0xFF)); // LSB
// Wire2.endTransmission();
//
// Wire2.requestFrom(deviceaddress,1);
HWire.beginTransmission(deviceaddress);
HWire.write((int)(eeaddress >> 8)); // MSB
HWire.write((int)(eeaddress & 0xFF)); // LSB
HWire.endTransmission();
HWire.requestFrom(deviceaddress,1);
// if (Wire2.available()) rdata = Wire2.read();
if (HWire.available()) rdata = HWire.read();
return rdata;
}
Please give detailed error description.
Look at an existing eeprom library how the stuff works.
The code writes a welcome message on termianl (EEPROM Test), then writes 0x55 on location 0 of EEPROM, then write on terminal window all the values of EERPOM locations starting from location 0 with a delay of one second.
With “software” version on terminal I can see the welcome message and then 0x55 0xFF 0xFF….
With “hardware” version I can see only welcome message.
I used a scope to see the activity on SCL line, but with the “hardware” code version nothing happens (it is fixed at 3.3V and no clock activity appears).
@Pito.
In an your previous post I saw that you used I2C2 with hardware implementation. My concern is the error I found in HardWire.cpp file. Mybe your version of Hwire library is slightly different… I could make a test using a previous version of repository.
Just to be sure: I2C2 is on PB10 (SCL2) and PB11 (SDA2), correct?
Thanks again for your support.
Luca
Another little step.
In file HardWire.cpp I modified HardWire::process in this way:
uint8 HardWire::process() {
Serial.println("1");
int8 res = i2c_master_xfer(sel_hard, &itc_msg, 1, 0);
Serial.println("2");
if (res == I2C_ERROR_PROTOCOL) {
if (sel_hard->error_flags & I2C_SR1_AF) { /* NACK */
res = (sel_hard->error_flags & I2C_SR1_ADDR ? ENACKADDR :
ENACKTRNS);
} else if (sel_hard->error_flags & I2C_SR1_OVR) { /* Over/Underrun */
res = EDATA;
} else { /* Bus or Arbitration error */
res = EOTHER;
}
i2c_disable(sel_hard);
i2c_master_enable(sel_hard, (I2C_BUS_RESET | dev_flags));
}
return res;
}
A year ago I’ve tested I2C second channel using HARDWIRE lib and after massive testing with logic analyzer and test points after every operator found out that I must use correct var size using I2C2.
I.e. instead of int you should use int16_t or uint8_t.
I2C1 works without it, but I2C2 works only with strict and correct var size int16_t or uint8_t
Including working example #1:
//#include <Wire.h>
#include <HardWire.h>
#define START PB0
HardWire HWire(2, I2C_FAST_MODE); // I2c1 , I2C_FAST_MODE SOFT_STANDARD
void setup() {
HWire.begin();
Serial.begin(115200);
pinMode(START, OUTPUT); //синхроимпульс для лог анализатора
digitalWrite(START,HIGH);
delay(1);
digitalWrite(START,LOW);
}
void loop() {
Serial.print("Light (lux): ");
Serial.println(get_lux());
delay(1000);
}
uint8_t read_register(uint8_t addr) {
uint8_t ret;
digitalWrite(START,HIGH);
delay(1);
digitalWrite(START,LOW);
HWire.beginTransmission(0x4A);
HWire.write(addr);
HWire.endTransmission();
HWire.requestFrom(0x4A,1);
ret = HWire.read();
digitalWrite(START,HIGH);
return ret;
}
float get_lux(void)
{
int luxHigh = read_register(0x03);
int luxLow = read_register(0x04);
int exponent = (luxHigh & 0xf0) >> 4;
int mant = (luxHigh & 0x0f) << 4 | luxLow;
return (float)(((0x00000001 << exponent) * (float)mant) * 0.045);
//return (float)((pow(2,exponent) * mant) * 0.045);
}
Thanks for your replay.
Today I tested the same code (hardware I2C version) on I2C1 and I can confirm that it works.
So I tried to correct var size as you suggested, and tested on I2C1: works OK.
Changed to I2C2 and doesn’t work. I will recheck var declarations.
My code now is:
//#include <Wire.h>
#include <HardWire.h>
#define EEPROM_ADDRESS 0x50 //Address of 24LC256 eeprom chip
HardWire HWire(2, I2C_FAST_MODE); // I2C2
void setup(void)
{
Serial.begin(115200);
delay(10000);
Serial.println("EEPROM Test");
HWire.begin();
uint16_t address = 0;
writeEEPROM(EEPROM_ADDRESS, address, 0x55);
while(1){
Serial.print(readEEPROM(EEPROM_ADDRESS, address), HEX);
Serial.print(" ");
address++;
delay(1000);
}
}
void loop(){}
void writeEEPROM(int16_t deviceaddress, int16_t eeaddress, uint8_t data )
{
uint16_t temp = 0;
HWire.beginTransmission(deviceaddress);
temp = eeaddress >> 8;
HWire.write((uint8_t)temp); // MSB
temp = eeaddress & 0xFF;
HWire.write((uint8_t)temp); // LSB
HWire.write(data);
HWire.endTransmission();
delay(5);
}
uint8_t readEEPROM(uint16_t deviceaddress, uint16_t eeaddress )
{
uint8_t rdata = 0xFF;
uint16_t temp;
HWire.beginTransmission(deviceaddress);
temp = eeaddress >> 8;
HWire.write((uint8_t)temp); // MSB
temp = eeaddress & 0xFF;
HWire.write((uint8_t)temp); // LSB
HWire.endTransmission();
HWire.requestFrom(deviceaddress,1);
if (HWire.available()) rdata = HWire.read();
return rdata;
}
Yes, PB10 == SCL2 and PB11 == SDA2
No, I have not try my code with last repository. Testing was done approx. a year ago in October 2016.
Can suggest you to do the following: use test points like serial.print(” TP1 “); before and after each wire operator to find bad line.
Then try to use different size var one after another – I succeed that way
May be some old code for second i2c was not carefully checked and wrong size variable leads to memory problems.
I tries as you suggested, but no luck (tried uint8_t, int ….).
I used this code:
#include <HardWire.h>
#define EEPROM_ADDRESS 0x50 //Address of 24LC256 eeprom chip
HardWire HWire(2, I2C_FAST_MODE); // I2C2
void setup(void)
{
Serial.begin(115200);
delay(10000);
Serial.println("EEPROM Test");
HWire.begin();
uint16_t address = 0;
writeEEPROM(EEPROM_ADDRESS, address, 0x55);
while(1){
Serial.print(readEEPROM(EEPROM_ADDRESS, address), HEX);
Serial.print(" ");
address++;
delay(1000);
}
}
void loop(){}
void writeEEPROM(int deviceaddress, uint16_t eeaddress, int data )
{
HWire.beginTransmission(deviceaddress);
HWire.write((int)(eeaddress >> 8)); // MSB
HWire.write((int)(eeaddress & 0xFF)); // LSB
HWire.write(data);
Serial.print(" TP1 ");
HWire.endTransmission();
Serial.print(" TP2 ");
delay(5);
}
int readEEPROM(int deviceaddress, uint16_t eeaddress )
{
int rdata = 0xFF;
HWire.beginTransmission(deviceaddress);
HWire.write((int)(eeaddress >> 8)); // MSB
HWire.write((int)(eeaddress & 0xFF)); // LSB
Serial.print(" TP3 ");
HWire.endTransmission();
Serial.print(" TP4 ");
HWire.requestFrom(deviceaddress,1);
if (HWire.available()) rdata = HWire.read();
return rdata;
}
here it is https://yadi.sk/d/NyZlmcEs3KBF3w
But smth tells me, that it will work absolutely the same
Yesterday I test the code using your repository image, but, as you already said me, it was the same.
But I noticed a thing: in your second working examples you call HWire.begin() function twice, one time in setup function and again in write_dac function.
If I call HWire.begin() twice, the second time I call it the code stop working (I tested it using Serial.print (” TPX “) before and after the HWire.begin() function).
I feel like that I2C2 in my case is not configured in a corrected way and when I try to write on it the code stuck.
So I have two questions: what kind of board are you using? I’m using Blue Pill.
The second question: I would like to use Serial.print in i2c.c library to make more deep debug. How can I use it? I tried but I have a compiler error. Or is another way to debug in i2c.c library without stlink?
Thanks again.
Luca.
I used to use (now not handy however) two I2C at once with MapleMini (or BP), ie:
HardWire HWire(1, I2C_FAST_MODE); // I2C1
HardWire HWire2(2, I2C_FAST_MODE); // I2C2On the same hardware, if I use the hardware implemetation of I2C2 (located on pins PB10 e PB11), I can’t write and read from external EEProm.
If I connect external EEProm on pins PB6 and PB7 (I2C1) I can read and write external EEProm with software AND hardware I2C library (Twowire and Hwire).
My declaration for I2C2 is:
HardWire H2Wire(2, I2C_FAST_MODE); // I2C2
srp
..
HardWire HWire(2, I2C_FAST_MODE); // I2C2
..
HWire.begin();
..
// Read 1 byte from the BMP085 at 'address'
char bmp085Read(unsigned char address)
{
unsigned char data;
HWire.beginTransmission(BMP085_ADDRESS);
HWire.write(address);
HWire.endTransmission();
HWire.requestFrom(BMP085_ADDRESS, 1);
while(!HWire.available())
;
return HWire.read();
}
// Read 2 bytes from the BMP085
// First byte will be from 'address'
// Second byte will be from 'address'+1
int bmp085ReadInt(unsigned char address)
{
unsigned char msb, lsb;
HWire.beginTransmission(BMP085_ADDRESS);
HWire.write(address);
HWire.endTransmission();
HWire.requestFrom(BMP085_ADDRESS, 2);
while(HWire.available()<2)
;
msb = HWire.read();
lsb = HWire.read();
return (short int) msb<<8 | lsb;
}
The first link is exactly the code I used. Infact it works (on I2C1 hardware and software version and I2C2 only software version).
I saw also the second link, but the function to read/write the EEProm are the same.
I tried also changing board (another Blue Pill) but with the same result.
I follow also the Winni_The_Pooh instructions changing variabile type, but doesn’t work.
The only main difference is that I use a Blue PIll (STM32F103C8) and you are using a MIni Maple (STM32F103CB), but the only difference seems to be flash memory…
I tried also to write I2C2 registers with Serial.print on the sketch, but nothing appares strange.
@zmemw16: how can I put hardware I2C in slow mode?
Luca
Today a made a simple test: using the SAME code, but compiling choosing “MiniMaple” instead “Generic STM32F103C Series”, the hardware I2C2 works
Now I have to understand why.
Luca.
[luca_stm32 – Tue Jun 20, 2017 11:39 am] –
Hi everybody.
Today a made a simple test: using the SAME code, but compiling choosing “MiniMaple” instead “Generic STM32F103C Series”, the hardware I2C2 worksNow I have to understand why.
Luca.
There is some speculation that some STM32F103’s are clones and not official ones. In which case it could explain why one board works and another doesnt.
I will PM @fpSTM and ask him if he knows of any clones
Yes, I’ve used blue pill.
I used the same hardware: Blue Pill and EEProm connected on I2C2 (pins PB10 and PB11).
In Arduino IDE, if I choose Tools->Board->Generic STM32F103C Series, the scketch doesn’t work (it stucks as soon as it tryes to send data on I2C2. In particular, it doesn’t pass H2Wire.endTransmission() that is the function that make the transmission start).
In Arduino IDE, if I choose Tools->Board->Maple Mini the scketch works as expected.
Important: in both cases I used the same hardware!
Now I’m trying to print STM32 registers to see differences. I noticed that using “Generic STM32F103C Series”, the SR2 register of I2C2 is 2 (busy) as soon I configure the pheripheral.
If I use “Maple Mini”, the SR2 register is 0.
Here is the code I’m using:
//#include <Wire.h>
#include <HardWire.h>
#define EEPROM_ADDRESS 0x50 //Address of 24LC256 eeprom chip
//Declare the instance that the users of the library can use
//TwoWire Wire(SCL, SDA, SOFT_STANDARD);
//TwoWire Wire2(PB10, PB11, SOFT_STANDARD);
HardWire H2Wire(2, I2C_FAST_MODE); // I2C2
//HardWire H1Wire(1, I2C_FAST_MODE); // I2C2
void setup(void)
{
Serial.begin(115200);
delay(10000);
Serial.println("EEPROM Test");
//Wire2.begin();
H2Wire.begin();
Serial.println("I2C2:");
Serial.print("CR1: ");
Serial.println(I2C2->regs->CR1, HEX);
Serial.print("CR2: ");
Serial.println(I2C2->regs->CR2, HEX);
Serial.print("OAR1: ");
Serial.println(I2C2->regs->OAR1, HEX);
Serial.print("OAR2: ");
Serial.println(I2C2->regs->OAR2, HEX);
Serial.print("DR: ");
Serial.println(I2C2->regs->DR, HEX);
Serial.print("SR1: ");
Serial.println(I2C2->regs->SR1, HEX);
Serial.print("SR2: ");
Serial.println(I2C2->regs->SR2, HEX);
Serial.print("CCR: ");
Serial.println(I2C2->regs->CCR, HEX);
Serial.print("TRISE: ");
Serial.println(I2C2->regs->TRISE, HEX);
Serial.print("PORTB CRL: ");
Serial.println(GPIOB->regs->CRL, HEX);
Serial.print("PORTB CRH: ");
Serial.println(GPIOB->regs->CRH, HEX);
Serial.print("PORTB ODR: ");
Serial.println(GPIOB->regs->ODR, HEX);
Serial.print("PORTB BSRR: ");
Serial.println(GPIOB->regs->BSRR, HEX);
Serial.print("PORTB BRR: ");
Serial.println(GPIOB->regs->BRR, HEX);
int address = 0;
writeEEPROM(EEPROM_ADDRESS, address, 0x55);
while(1){
Serial.print(readEEPROM(EEPROM_ADDRESS, address), HEX);
Serial.print(" ");
address++;
delay(1000);
}
}
void loop(){}
void writeEEPROM(int deviceaddress, int16_t eeaddress, uint8_t data )
{
// Wire2.beginTransmission(deviceaddress);
// Wire2.write((int)(eeaddress >> 8)); // MSB
// Wire2.write((int)(eeaddress & 0xFF)); // LSB
// Wire2.write(data);
// Wire2.endTransmission();
H2Wire.beginTransmission(deviceaddress);
H2Wire.write((int)(eeaddress >> 8)); // MSB
H2Wire.write((int)(eeaddress & 0xFF)); // LSB
H2Wire.write(data);
H2Wire.endTransmission();
delay(5);
}
uint8_t readEEPROM(int deviceaddress, uint16_t eeaddress )
{
uint8_t rdata = 0xFF;
// Wire2.beginTransmission(deviceaddress);
// Wire2.write((int)(eeaddress >> 8)); // MSB
// Wire2.write((int)(eeaddress & 0xFF)); // LSB
// Wire2.endTransmission();
// Wire2.requestFrom(deviceaddress,1);
H2Wire.beginTransmission(deviceaddress);
H2Wire.write((int)(eeaddress >> 8)); // MSB
H2Wire.write((int)(eeaddress & 0xFF)); // LSB
H2Wire.endTransmission();
H2Wire.requestFrom(deviceaddress,1);
// if (Wire2.available()) rdata = Wire2.read();
if (H2Wire.available()) rdata = H2Wire.read();
return rdata;
}
This could make the difference between boards.
I suggest to use always the PXY notation (PA2, PB10) instead of raw numbers (like 2, 33, etc) to make it more generally usable.
I use the function:
HardWire H2Wire(2, I2C_FAST_MODE); // I2C2Alternative function mapping does not take place because the dev_flags does not contain the remap flag.
And I2C2 cannot be remapped, it is fixed to PB10/11.
And yes, it seems that the reset should come only before init and GPIO config. This looks like a bug!
So the correct sequence should be:
/* Turn on clock and set GPIO modes */
i2c_init(dev);
i2c_config_gpios(dev);
/* Reset the bus. Clock out any hung slaves. */
if (flags & I2C_BUS_RESET) {
i2c_bus_reset(dev);
}
It could be the BP variant has got a bug in some defines (compare BP and MM variants).
constructor has a defaulted parameter for the mode
HardWire HWire(2, I2C_FAST_MODE); // I2C2
HardWire HWire(2); // I2C2 slow mode
[zmemw16 – Tue Jun 20, 2017 5:53 pm] –
thought i’d posted this already
constructor has a defaulted parameter for the mode
HardWire HWire(2, I2C_FAST_MODE); // I2C2
HardWire HWire(2); // I2C2 slow mode
This is exactly what I did. I compiled the sketch for MM and worked.
@Stevestrong
Yes, compare the MAP files generated for MM and BP is what I would like to do.
I would like also to correct the initialization of I2C.
Luca.
With a friend of mine we found the problem.
It is located if boards.h (under the directory STM32F1\vaiants\generic_stm32f103c\board).
The difference respect board.h of Maple Mini is the line where is defined pin that control USB disconnection via external transistor.
#define BOARD_USB_DISC_DEV GPIOB
#define BOARD_USB_DISC_BIT 10
The i2c init should set it as “open_drain” then..
https://community.st.com/thread/24199
In this tread, I found the following sentence:
I solved this issue by changing the initialization order from that shown in your code. First initialize the I2C port pins as I2C function pins( open collector) and enable their RCC module, then start the I2C RCC module running.
So I think it could be better to modify also i2c_master_enable function in i2c.c in this way:
void i2c_master_enable(i2c_dev *dev, uint32 flags) {
/* PE must be disabled to configure the device */
ASSERT(!(dev->regs->CR1 & I2C_CR1_PE));
/* Ugh */
_i2c_handle_remap(dev, flags);
i2c_config_gpios(dev); // first, initialize gpio. Or call it before _i2c_handle_remap(dev, flags);?
/* Reset the bus. Clock out any hung slaves. */
if (flags & I2C_BUS_RESET) {
i2c_bus_reset(dev);
}
/* Turn on clock and set GPIO modes */
i2c_init(dev);
Infact the function i2c_master_enable calls i2c_bus_reset that calls i2c_master_release_bus. In this last function, gpio configuration is performed.
So it seems that gpio configuration is made before i2c is enabled.
I noticed this event. With the original repository files, selecting generic_stm32, printing the I2C2 registers, I saw that after I2C2initialization SR2 was 2 (I2C busy). Selecting MM (that use PB9), after I2C2 initialization SR2 was 0 (not busy).
Maybe that when USB drive external transistor on PB10, it generate a condition to I2C pheripheral.
So resetting I2C pheripheral could be sufficient to make it work. But more in general, on BP, you could use PB10 as input. In this case, USB initialization set PB10 as output and drive it high and low. This can potentially damage the external circuit of BP connected to PB10.
Luca.
With sw wire I2C init() sets the P10 as an “open-drain” and it works.
If the generic boards are doing this, its a bug, and the MM code needs to be #if def’ed out
Today I tested your last repository: it works!
I made also a comparison between sofware implementaion and hardware implementation of I2C. The difference is 880 bytes (software implementaion takes less memory than hardware implementation).
Thanks again!
Congratulations (all of you) again for your good work.
Luca.
i checked to see if the address of eeprom that i m giving is correct with an I2C scanner and i get 0x50 . So its there and suposed that it works
my EEPROM is connected into HardWire HWire(2, I2C_FAST_MODE);
ATMLH712-02CM
Port Label
PCB-GND 1 A0 0
PCB-GND 2 A1 0
PCB-GND 3 A2 0
PCB-GND 4 GND
MCU – 22(PB11) 5 SDA RES-1K to VCC
MCU – 21(PB10) 6 SCL RES-1K to VCC
PCB-GND 7 WP Read/Write
PCB-1 8 VCC
My libraries are the latest . with the latest wire.h enhancement of hardwire, but also with RogerClark bug fixes
I tried both SoftWire and HArdWire
i m using st-link to upload the code into the STM32F103C8T6
PS. Did you try using normal / slow I2C speed
[RogerClark – Sat Aug 05, 2017 11:49 pm] –
You should post this to a new topic as it sounds like its related to that specific EEPROMPS. Did you try using normal / slow I2C speed
Yes i tried with
HardWire HWire(2, I2C_FAST_MODE); and
HardWire HWire(2);
But no,,
It probably should default to slow, so this is something that I need to fix
