I2C power-up sequence

E

edmunds

Senior Member
Dear all,

I'm working on a project, where I have picaxe 40x2 controlling 9 different I2C slaves - LED drivers, battery fuel gauge, 6DOF IMU, EEPROM, distance and ambient light sensor, motor driver and miniature OLED for debugging on scene. It is all coming together slowly - haven't conquered the IMU yet (a very long register map :)), but the rest of the devices are responding.

I can get everything to work, but I have noticed about every other time I have to unplug the battery and plug it in again for the system to work. It's like the I2C bus would need a restart or something. I do not have a reset button on the system, so I cannot say if resetting the picaxe alone would help or not.

The power is provided by TOREX XC206 2.85V DC/DC converter.

Any ideas?


Thank you for your time,

Edmunds
 
hippy

hippy

Technical Support
Staff member
If the I2C bus is locking up then explicitly unlocking it should help, but there should be no reason the bus does lock up unless an I2C interaction ends mid-stream, before it completes, or communications on the I2C bus is incompatible with some I2C device which causes it to go into a non-responsive or bus disrupting state.

It may be worth examining your program to see if there is something which is causing the lock up as it would be better to avoid that rather than resolve it after that happens.
 
E

edmunds

Senior Member
Buzby said:
This might help : http://www.picaxeforum.co.uk/showthread.php?19694-Does-12c-lock-up
Click to expand...
@Buzby, thank you for the link. I think the @Technical link in there to the this post might be the key to the solution. However, if the explanation by the OP of that old post is correct, then the code snippet provided by another user underneath isn't. IMHO.

If the bus gets locked because some slave is pulling SDA low during initialisation, then checking if it is high and then doing something about it is definitely not a way to solve the problem. I'm offline from my picaxe, but with some discretionary time, so not tested, but something like this could work:

Code: 
#rem
Code snippet to make sure I2C starts up properly, v.1.0, 2015
#endrem

#picaxe40x2
#no_data
#no_table

'I2C pins on 40X2
Symbol pinSCL = pinC.3
Symbol SCL = C.3
Symbol pinSDA = pinC.4
Symbol SDA = C.4

'Byte variables
Symbol Counter = b4

'Word variables

'Constants
Symbol SCLPulse = 100                '50ms @ 8MHz
Symbol SCLPause = 100               '50ms @ 8MHz
Symbol I2CSpeed = I2Cslow

'I2C addresses
Symbol I2CDevice = 0x52


'Initialisation
init:
  gosub InitSDA
  hi2csetup i2cmaster, I2CDevice, I2CSpeed, i2cbyte
'  gosubTestI2C  
  
main:

goto main


InitSDA:
  if pinSDA = 0 then                       'Check if SDA pin is low    
'    Sertxd ("SDA was low!!!", CR, LF)
  	do
  		pulsout SCL, SCLPulse              'If yes, pulse SCL until ...
  		pause SCLPause
  	loop while pinSDA = 0               '... able to pull high
  endif
  pause SCLPause
return

TestI2C:
  hi2cout 0, (100)
  pause 5
  hi2cin 0, (b0)
  Sertxd (#b0, CR, LF)
return
 
E

edmunds

Senior Member
Dear all, especially @Technical,

The above code works and I do not seem to have the problem anymore, however, I'm starting to think there is something that can be improved in the firmware if I am right and the code above would not be needed. Forgive me and forget this, if I'm mistaken :)

Under hi2csetup command, the firmware must be doing setting the port (pin) state and the port as input/output. Could it be, that the code sets SDA as output (zero or low by default) and only then sets the pin high, thus creating the unnecessary edge transition that triggers some or all devices to respond by pulling the line low? If that turns out to be true, the solution is as simple as setting the state before setting the port (pin) in those crazy pic registers :).


Regards,

Edmunds
 
Technical

Technical

Technical Support
Staff member
The issue is not with the PICAXE chip or as you describe, it is with the slave chip being left 'suspended' in a partially clocked state (ie. for example, when its done 6 out of 8 expected clock pulses). This can occur if you reset the PICAXE chip (e.g. a new download) without resetting the slave as well.

Your workaround sends dummy pulses to the slave to clock out any remaining leftover bits (e.g. the 2 the slave still expects) so that the slaves are not incorrectly suspended any more.
 
Last edited:
E

edmunds

Senior Member
Dear @Technical,

Thanks for the clear explanation. However.

Technical said:
This can occur if you reset the PICAXE chip (e.g. a new download) without resetting the slave as well.
Click to expand...
My problem is power cycling, not downloads. I don't like workarounds and strange things in the code if it is possible to avoid them. And I cannot figure out what else could be wrong and yes, maybe it is time to take the logic analyzer out :).

Edmunds
 
You must log in or register to reply here.
Top