GLK19264a handshake bug ?

LK/ELK/VK/PK/OK/MX/GLK/EGLK/GVK/GLT Series

Moderators: Henry, Mods

Post Reply
paulplasma
LCD?
Posts: 4
Joined: Mon Aug 17, 2009 6:49 am

GLK19264a handshake bug ?

Post by paulplasma » Fri May 05, 2017 8:23 am

Our product used the GLK19264 to display like a spectrum analyzer. This worked great until we were forced to use the GLK19264a. Our UART is running 115.2k baud and is double buffered. So even after we receive the software handshake indicating your buffer is full a few extra bytes go out. Normally you respond with an 0xFE with each extra byte you receive but once in a while you follow the last 0xFE immediately with a 0xFF indicating the buffer is empty enough to accept more data (and it is not ready). We then try to finish sending our large packet which definitely overruns your buffer and causes erratic behavior. Normally it just results in garbled characters on the pretty SpecAn screen but sometime it does nasty things like resetting the display or worse like changing the baud rate and no longer responding. This does not happen on the older GLK19264 (I still have ones in the lab to do back to back testing) only on the GLK19264a. Note due to compatibility reasons we must roll the display firmware back to 8.4.
Has this bug been seen before? Is there a work around? Can we buy old GLK19264 displays?

Daniel Divino
Matrix Orbital
Matrix Orbital
Posts: 78
Joined: Thu Sep 24, 2015 9:38 am

Re: GLK19264a handshake bug ?

Post by Daniel Divino » Fri May 05, 2017 10:20 am

Hi Paul,

I understand that you are facing a few issues regarding the GLK19264A's software flow control.Have you adjusted the "Almost Full" and "Almost empty" values using the "Turn Software Flow Control On" command (1.7 in the GLK19264A manual)? Using this command, you will be able to adjust the software flow control buffer levels, and change when the display send the "Xon" and "Xoff" bytes.

From the factory, the display will return the Xoff byte (Almost Full) when there is only 5 bytes left. The display will also return the Xon byte (Almost empty) when there are 251 bytes empty. If these values are changed incorrectly you may get a premature Xon byte. IE the display can be programmed to issue an Xoff byte when there are 5 bytes left, and programmed to return a Xon byte when there are 6 bytes free. This would continually let you know there is space free in the buffer when in reality you have about 6 bytes.

I suggest you try to modify the Almost Full and Almost Empty values to account for your buffer delay Increasing the "Almost Full" value will ensure that the few extra bytes that get sent out are still accepted by the display. Increasing the "Almost Empty" value will ensure that the Xon value isn't returned until there is definitely enough space to accept your next packet of data.

Cheers,
Dan
Daniel Divino
Technical Support
Matrix Orbital

paulplasma
LCD?
Posts: 4
Joined: Mon Aug 17, 2009 6:49 am

Re: GLK19264a handshake bug ?

Post by paulplasma » Fri May 05, 2017 10:45 am

Sorry I left that part out but yes I messed with the values quite a bit (especially back in development using the rev1pcb which only had 128 byte buffer nothing worked correctly until I changed them). On power up here is what I write out first...
dispTxBuf[dispTxHdPtr++] = 254; // command
dispTxBuf[dispTxHdPtr++] = 0x3A; // command for flow ctrl
dispTxBuf[dispTxHdPtr++] = 48; // bytes left flag full
dispTxBuf[dispTxHdPtr++] = 84; // bytes flag empty

With the new larger buffer version I have tried values like 100,200 and much more with no change in behavior.
Again it works flawless with the older display.

Daniel Divino
Matrix Orbital
Matrix Orbital
Posts: 78
Joined: Thu Sep 24, 2015 9:38 am

Re: GLK19264a handshake bug ?

Post by Daniel Divino » Fri May 05, 2017 4:38 pm

Hi Paul,

Could you provide a few details regarding the size of the data chunk you are sending, and how frequently you send it? I would like to try and replicate the issue here as closely as possible.

Cheers,
Daniel
Daniel Divino
Technical Support
Matrix Orbital

paulplasma
LCD?
Posts: 4
Joined: Mon Aug 17, 2009 6:49 am

Re: GLK19264a handshake bug ?

Post by paulplasma » Mon May 08, 2017 8:51 am

It should not matter the size etc. Just always write 3 extra bytes and every now and then it will quickly follow the 0xFE with an 0xFF. But since you asked I am bursting approx 2500 bytes once a second. The normal handshake induced 'pause' is 10ms the second screenshot shows the bug induced 'pause' shown in the second scope plot is approx 500us.
dispHandshakeNormal.jpg
dispHandshakeNormal.jpg (90.75 KiB) Viewed 39 times
dispHandshakeBug.jpg
dispHandshakeBug.jpg (94.5 KiB) Viewed 39 times

Daniel Divino
Matrix Orbital
Matrix Orbital
Posts: 78
Joined: Thu Sep 24, 2015 9:38 am

Re: GLK19264a handshake bug ?

Post by Daniel Divino » Mon May 08, 2017 4:00 pm

Hi Paul,

I've done a couple of tests regarding the the software flow control. I wasn't capable of fully replicating your scenario, but I was able to get something similar. For my testing, I am sending data to the display every 10ms, and monitoring the returns coming from the display.

As I attempted to replicate your data stream, I found that the display would start to crash, and even change its baud rate, brightness, contrast etc just as you said. I was able to fix this issue by reducing how many bytes I'm sending to the display at once, reducing how frequently I updated the display, and adjusting the software flow control threshold values.

In the end, I was sending roughly 50 bytes every 10ms to the display with no issues. I adjusted my threshold values to ensure that even if a '254' was returned, indicating the buffer was full, I could be certain there was enough space in the buffer to fit my 50 byte data packet, preventing dropped bytes. Increasing the data packet size to 100-150 bytes is possible, but the software flow control thresholds would need to be adjusted appropriately to prevent lost bytes.

Ultimately, I suggest you add a delay to reduce the amount of bytes being dropped. Rather than sending 2500 bytes at once, try dividing that to 250 bytes every 10ms. You can also adjust your flow control thresholds to ensure that the bytes lost remain as minimal as possible.

If you still face issues even with these fixes in place, you can contact sales@matrixorbital.ca and discuss any options for ordering older GLK19264 revisions.

Cheers,
Daniel
Daniel Divino
Technical Support
Matrix Orbital

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest