I2C lockup with 'corner block' chars.
Posted: Mon Aug 13, 2007 1:32 pm
Hello from a first time poster.
We are using the LK162-12-E part, rev 2.3 according to our hardware guy. It works at 83kbps (driven by ColdFire 5206) for some indeterminate amount of time, and then locks up into a mode where is displays multiple versions of an unusual character that looks like the upper right side of a square with a dot in the middle. It then stays that way until the system is power cycled. Debugging the driver code shows an arbitration loss error.
My first question involves an excerpt from the 3.0 manual:
------------------------------------------------------------------------------
The LK162-12 has some speed limitations, especially when run in I2C mode. Here are some considerations
when writing I2C code:
* to be able to read the replies of query commands (eg. cmds 54, 55) the following command must be
sent (only needs to be sent once, so this can be done somewhere in init): 254 / 160 / 0 this command puts
the reply data in the I2C output buffer instead of the RS232 output buffer. Please note that due to a 16 byte
output buffer, query commands that reply with more than 16 bytes cannot be read (eg cmd Get FileSystem
Directory)
* 3ms delay between the read commands
* 625us delay in between data bytes within a transaction is necessary
* 375us between transactions is necessary
---------------------------------------------------------------------------------
I have no need to query the display but, Do the 625us/375us delays apply to -sending- commands to the rev 2.3 as well?
Also, I reset the I2C controller on the micro after every transaction 'session' with the display but this does not seem to be enough to pull the display out of whatever mode it gets into. Is there a bit sequence I can apply that will 'reset' the display?
Thanks for any help you can offer on this.
R. G. Sheehan
Cameron
We are using the LK162-12-E part, rev 2.3 according to our hardware guy. It works at 83kbps (driven by ColdFire 5206) for some indeterminate amount of time, and then locks up into a mode where is displays multiple versions of an unusual character that looks like the upper right side of a square with a dot in the middle. It then stays that way until the system is power cycled. Debugging the driver code shows an arbitration loss error.
My first question involves an excerpt from the 3.0 manual:
------------------------------------------------------------------------------
The LK162-12 has some speed limitations, especially when run in I2C mode. Here are some considerations
when writing I2C code:
* to be able to read the replies of query commands (eg. cmds 54, 55) the following command must be
sent (only needs to be sent once, so this can be done somewhere in init): 254 / 160 / 0 this command puts
the reply data in the I2C output buffer instead of the RS232 output buffer. Please note that due to a 16 byte
output buffer, query commands that reply with more than 16 bytes cannot be read (eg cmd Get FileSystem
Directory)
* 3ms delay between the read commands
* 625us delay in between data bytes within a transaction is necessary
* 375us between transactions is necessary
---------------------------------------------------------------------------------
I have no need to query the display but, Do the 625us/375us delays apply to -sending- commands to the rev 2.3 as well?
Also, I reset the I2C controller on the micro after every transaction 'session' with the display but this does not seem to be enough to pull the display out of whatever mode it gets into. Is there a bit sequence I can apply that will 'reset' the display?
Thanks for any help you can offer on this.
R. G. Sheehan
Cameron