GTT70 TTL Tx / Rx flip

[sean173]

Hello,

I am having trouble getting any return message out of my GTT70A-TPC-BLM-B0-H1-CT-V5. I can send text to the display and it displays it, but when I attempt to use the echo command (254 255) or the get protocol revision (254 0) I get only a constant 3.3V high activity on the Tx line coming from the module with no load attached to this pin except for a high impedance o'scope probe.

I should say that I did have the Tx of my 3.3V UART output connected incorrectly to the Tx of the module and the Rx connected to the Rx, but after swapping the connections per the troubleshooting guide, I can only get it to display text and perhaps get it to reset, but not get it to echo or report revision information.

This is with RTS <-> RTS and CTS <-> CTS, and with or without hardware flow control turned off (254 58).

Also, i have verified the baud rate from my FPGA (with microcontroller and UART instantiated internally) as being within the 3% spec of the nominal 115.2kbaud using a o'scope. I have even tried routing out the four control signals to a new set of FPGA GPIO pins and used those with the same results. So it looks like the Tx output of the module is stuck high.

Is it likely that having the RX and TX not cross connected as designed damaged the output driver of the Tx output of the module?

What else might be wrong?

Sean

[Raquel]

Hello Sean,

Thank you for posting on the forum.

I think you have done pretty good troubleshooting.
My first thought was for turning off flow control which you have done. Please make sure though that command sent is 254 58 0.
If this still does not work, I think the TX line may have been damaged as you suspect.

Thank you,

[sean173]

Hi Raquel,

I will try to turn off flow control with 254 58 0 as you suggest.

I tried using the I2C interface and didn't receive an ack bit (asserted low) as I would have expected when doing a read or a write request. I have attached a screen shot of SDA and SCL lines during this transaction. As you can see, the ACK bit stays high and the display never pulls it low. The data rate is 100kbps per the spec and the pull-up resistances I used are both 6.8k to 3.3V.

I2C transaction Scope Screen Shot

I2C_transaction_no_ack.png (119.24 KiB) Viewed 399 times

Sean

[Raquel]

Hello Sean,

It looks like you are addressing the GTT70A with 0xA0. Can you please try 0x50?

Thanks,

[sean173]

Hi Raquel,

Thank you for your help, I did some further testing on the I2C bus and tried the following commands which resulted in an ACK, but no response on the I2C bus:
{254, 0}; // get module protocol revision
{254, 55}; // get module type, should be 37636d = 1001 0011 0000 0100
The second command has a corresponding screen shot shown below. I looked out in time as far as 500ms past the end of the command and there was no reply or bus assertion of any kind by the module. I even switched to using 4.7k pull ups to make the edges faster. I tweaked the SDA hold time to make sure SCL deasserted more than 500ns before SDA deasserted, but this too didn't seem to have an effect. See attachment.

-Sean

I2C_transaction_ack_but_no_response_to_0xFE_0x37_get_module_type.png (106.32 KiB) Viewed 356 times

I2C_transaction_sda_to_scl_timing.png (107.06 KiB) Viewed 356 times

I think that whatever is going on is somehow internal to the I2C and UART interface blocks on the microprocessor of the module. I am thinking also about trying a firmware upgrade or refresh.

Sean

[Raquel]

Hello Sean,

Good to hear that you get ACKs from the display now.
In order to get the GTT70A to reply via I2C, you will need to set the communication channel to I2C.
You may please check command 254 5 from the manual.

With I2C, all communication transactions are master initiated.
To read back replies from query commands such as 254 0 and 254 55, you will need to start a read transaction (after sending the query command) with the read address 0x51, followed by sets of clock cycles to get the reply from the display.

[sean173]

I am having difficulty with my I2C master interface getting it to respond for a read operation after reading your last post and attempting to follow it carefully.

1. I can set the communications channel to I2C with 254 5 2 as you pointed out and get an ACK.

2. I can follow this up with a write scratchpad command {254, 204, 10, 10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10} which I intend to write 10 bytes to offset index 10 and get an ack.

3. I can then send a read scratchpad command {254, 205, 10, 10} and get an ack.

4. I can then follow this with a read command by sending the slave address and followed by 10 SCL cycle bursts of 8 bits on the bus and get 0 255 255 255 255 255 255 255 255 255 returned from the slave.

Here is a response picture showing the final read command.

Final_Read_Request_After_ScratchPad_Write_and_Read.png (114.06 KiB) Viewed 288 times

I should note that I am releasing the bus between every step listed above with SCL and SDA asserted high, but thought that maybe I should be doing a "Repeated Start" operation at some point in the sequence, maybe between steps 3 and 4 so that the bus is not de-asserted then, but that wasn't successful either. Here is a link to an App note from TI describing Rpeated Start protocol. https://www.ti.com/lit/an/slva704/slva704.pdf

Thank you for your patience in helping me. It is greatly appreciated.

[Raquel]

Hi Sean,

Please try simpler commands for now: 254 0 or 254 55 as you mentioned earlier.
I think you are not giving the write and read scratch pad commands the right parameters.

I wonder if you are taking advantage of the driver code we provide:
Firmware\Client\gttclient

Thank you,

[sean173]

Hi Raquel,

Success! I was able to use the I2C bus decoding feature of my oscilloscope software to decode quickly and concisely the transactions going on and I have it mostly working....well enough I guess. This plot shows the {254, 55} command to fetch the module ID. I thought it should be 37636 decimal which converts to 0x9304 but it seems that what I read was 0x930D, which seems to be slightly different than what revision 2.7.1 of the GTT70A protocol manual states.

Read_module_ID_0x93_0x0D_success.png (150.08 KiB) Viewed 263 times

Also, I was able to read out the Module ID string as shown here as "GTT70A" after converting the hex to ASCII.

Read_module_ID_String_success.png (149.2 KiB) Viewed 263 times

I was wondering though what the purpose of the <00> byte is in the return string of <28> <FC> <37> <00> <02> <93> <0D>. Is this just the most significant byte of a two-byte length field?

Thanks again for your help.

Also, because I am using low level drivers specifically designed for the I2C hardware interface soft-IP block in my FPGA, I am kind of locked in and have to adapt my code to talk to that block, or write my own I2C interface in VHDL and custom drivers, which I didn't really want to get into at this point. So I am happy with what I have going on right now.

Regards,

Sean

[Raquel]

Hello Sean,

Please check Return Message for command 254 55 in the manual.
37645 is the correct module number for the GTT70A-TPC
37636 is for the TPR model; sorry the manual only lists the TPR models

Thank you,