I have a rather large program (3631 bytes) which has a master 28x2 communicating with several i2c slaves, one of which is another 28x2. I pull data from an external eeprom, send text to an OLED, and get timing from an RTC. All works well until I get to a certain part of the code. Then the master loses the ability to communicate with the slave 28x2 (it can still pull data from the eeprom and send it to the OLED).
One would think that was a simple coding problem and I spent a good week trying to find it. No such luck. I'm using the same subs that communicate successfully earlier in the program and introduce no new variables. I've even isolated the variables (push and pop with sp) to be sure. I've checked that I'm not overwriting parts of the sp (checked on both master and slave) to corrupt my data. And I've checked the slave side, which is behaving as it should. It gets all the proper transmissions until the master blows up. Then it gets nothing.
I've checked and rewritten portions of the code and tried various workarounds, all to no avail. As I said, the code is large, taking almost all of slot 0, and I have some portions running out of the other 3 slots. But where it blows up, it has already returned from slot 2 and communicated with the slave successfully several times. When it blows up, the slave receives nothing, but the master "reads" the slave sp locations I have set up for communications and reports that it sent a 255 and that the slave has answered with a 117.
My communication codes are all in the range of 0 - 40. I know that a 255 will come up if the master can't read the slave, but notice that I don't get two 255s. Also keep in mind that the slave end actually gets none of this. It seems to me that the master is suddenly lost and reading another address or another slave. But I call the hi2csetup with the correct parameters just prior to the problem. So that shouldn't be. Once the master blows up, it stays in that mode. It doesn't eventually straighten out even though I have it re-trying. (Keep in mind that master continues to communicate with external eeprom and OLED during this time.)
These are the slave addresses I'm using:
;i2c addresses
symbol slave_addressA = %10110000 ;slave address for 28x2 = 176
symbol RTC_addr = %11010000 ;address of slave RTC = 208
symbol lc256_addr = %10100000 ;$A0 eeprom address = 160
symbol OLED_ADDR = %01111000 ;$78 OLED I2C address = 120
One possibility is that the master briefly relinquishes the ic2 bus so that the slave can become master, read the external eeprom, and then go back into slave mode. It's just a quick read, and the slave does it successfully. I have the timing on the master side set up so there should be no chance of collision (I've even tried increasing the hi2csetup off time on the master side to no avail).
My only guess at this point is that there is some kind of overflow taking place that affects whatever memory space hi2c is using. Is that possible? Has anyone run into anything like this?
Hardly any hair left !!!
John
One would think that was a simple coding problem and I spent a good week trying to find it. No such luck. I'm using the same subs that communicate successfully earlier in the program and introduce no new variables. I've even isolated the variables (push and pop with sp) to be sure. I've checked that I'm not overwriting parts of the sp (checked on both master and slave) to corrupt my data. And I've checked the slave side, which is behaving as it should. It gets all the proper transmissions until the master blows up. Then it gets nothing.
I've checked and rewritten portions of the code and tried various workarounds, all to no avail. As I said, the code is large, taking almost all of slot 0, and I have some portions running out of the other 3 slots. But where it blows up, it has already returned from slot 2 and communicated with the slave successfully several times. When it blows up, the slave receives nothing, but the master "reads" the slave sp locations I have set up for communications and reports that it sent a 255 and that the slave has answered with a 117.
My communication codes are all in the range of 0 - 40. I know that a 255 will come up if the master can't read the slave, but notice that I don't get two 255s. Also keep in mind that the slave end actually gets none of this. It seems to me that the master is suddenly lost and reading another address or another slave. But I call the hi2csetup with the correct parameters just prior to the problem. So that shouldn't be. Once the master blows up, it stays in that mode. It doesn't eventually straighten out even though I have it re-trying. (Keep in mind that master continues to communicate with external eeprom and OLED during this time.)
These are the slave addresses I'm using:
;i2c addresses
symbol slave_addressA = %10110000 ;slave address for 28x2 = 176
symbol RTC_addr = %11010000 ;address of slave RTC = 208
symbol lc256_addr = %10100000 ;$A0 eeprom address = 160
symbol OLED_ADDR = %01111000 ;$78 OLED I2C address = 120
One possibility is that the master briefly relinquishes the ic2 bus so that the slave can become master, read the external eeprom, and then go back into slave mode. It's just a quick read, and the slave does it successfully. I have the timing on the master side set up so there should be no chance of collision (I've even tried increasing the hi2csetup off time on the master side to no avail).
My only guess at this point is that there is some kind of overflow taking place that affects whatever memory space hi2c is using. Is that possible? Has anyone run into anything like this?
Hardly any hair left !!!
John
Attachments
-
44.8 KB Views: 7
Last edited by a moderator: