I have a SC18IM700 but instead of sending "OK" it is sending long streams of "O" and then long streams of "T",
Does anyone have any idea what this means?
Please attached your test waveform and your schematic.
1) have you tried using another SC18IM700 ? maybe the one you are using is faulty.
2) have you checked what happens at power-up on vcc and gnd ? Maybe it's caused by a startup brownout.
3) have you tried to send commands to the device ? Does it replies correctly when trying to read one of its internal registers ?
I used SC18IM700 recently, it has some quirks that may cause problems while using it for the first time in a project, , especially how internal state machines operate the UART<-->I2C bridging.
i.e. it seems that some commands can be overlapped (current command executes I2C transaction while a new command is loaded from UART) but there are situations where the UART-side state machine gets paused and overlapping doesn't work, it also seems it depends on UART and I2C bps settings, etc. etc.)
I guess more detailed documentation from NXP would be helpful.
Unfortunately I never got past the start-up condition as my software got very confused with the stream of 'O' and 'K's.
When you are operational, does the 'OK' message come across as 'OK' or as 'O''O''O''O''O''O''K''K''K''K''K''K'?
that's what I was seeing (but the 'K' was a 'T')......
Looking at my bus, I think the SDA line is being held low by an unconfigured device which may be the cause of the crazy behaviour.
At start-up you receive a single 'OK' at 9600bps 8N1, but only if the chip resets correctly.
About the SDA line being held low, it's likely the source of your problem.
In my previous post I wrote about some issues about SC18IM700 internal state machines, based on what happened developing my project, instead of two indipendent state machine (one on the UART facing side, another on the I2C side, sharing data by way on an internal buffer) it seems there are more dependencies and interlocks between the UART and I2C sides than those implied in the (too spartan) documentation provided by NXP.
That is, I2C issues may cause troubles on the UART side even if you are not sending commands to I2C.
So I solved the problem with the SC18IM700.
My external interface is RS422 and I am using an ADM2585E which outputs LVCMOS. The input to the SC18IM700 is RS232. RS232 has upside down logic, i.e. logic high '1' is 0V or Negative and logic low '0' is 3V or positive. Because of this inverse logic, the input was being held in the logic high state. This was causing the chip to enter an unknown state where behind it sent continuous streams of 'O' and 'T's. Also it didn't respond to any commands because the signal was the inverse to what it expected. Reversing my signals on the RS422 side instantly cured the problem, allowing the SC18IM700 to start up correcty and send its single 'OK' command. I was able to read internal registers and output data on the I2C.
Retrieving data ...