Unreliable Bitmap up-load on GLK19264-7T-1U (USB)

[kevan.t]

This post may be related to my other post today - in that I get either one of the problems.

After a few hours of normal operation, my GLK19264-7T-1U (USB) stops accepting bitmap uploads properly. It gets part-way through a 1538 byte bitmap upload and then returns a bad echo byte, at which point my upload code aborts with an error (quite correctly). I sent 0x00 and the echo was 0xFF.

Two smaller uploads had already completed successfully before the large one that fails. Both were less than 20 bytes each.

Again, I cannot seem to fix this problem. I have powered-down and re-started the PC, wiped the file system, restored factory settings.

What could I be doing wrong? Prior to this fault I had uploaded the same bitmap several times without problems. Also, the code had not changed when the fault started to occur.

Interestingly, MOGD# is able to upload Ok. Perhaps I have a dodgy serial port configuration. Can you supply a definitive configuration that I can set from my C++ code?

Please help !!!

[kevan.t]

I was wrong about MOGD# - when the display is in this state, MOGD# cannot upload to it either.

So far the display has failed to recover and is presently unusable. I am going to switch it off and go home for the weekend. Perhaps it will be Ok on Monday...

[Clark]

Hi Kevin,

I see you've got two posts up here, and it looks to me like they are related, so I'll just answer here.

I have noticed that some of our graphic displays have exhibited similar behavior to the upload difficulty you have described. We've taken a look at a few different cases, but unfortunately have not yet come up with a concrete cause.

As for a solution, working primarily with fonts, I've found that uploading the largest files first seems to produce better results. I believe this has something to do with the file structure of the memory chip on board, but as you've noticed, this problems seems to come and go, so we're still looking into it.

Anyway, give that a shot, I believe the trouble reading the file directory as well as uploading is a result of a problem with the inboard memory in general, and one should clear up with the other.

Let me know what you find, and if you've got any further questions regarding that display.

Thanks,
~Troy

[kevan.t]

Thanks for the advice.

This seems to be an ongoing issue with the filesystem, so I'll keep looking for work-arounds.

For your information: I can get the device back into a usable state by using MOGD# to wipe the filesystem, then uploading a font or a bitmap, again using MOGD#.

Then, I have modified my code to upload my large file first, and only do any upload at all if they are not already resident on the device.

Fortunately I only have one large file to upload (at present). Hopefully I will not need any more. "Draw Direct" is just too slow for large bitmaps.

I have now managed to get my bitmaps and font onto the device using the above approach. This allows me to continue. However, I really would appreciate any further updates as they become available. We need to use the features of this device as they are advertised and would prefer not to be constrained by faults in its embedded software.

Once again, I appreciate your concern and your prompt responses.

regards

Kevan

[Clark]

Hi Kevan,

Great to hear that you've got your display uploaded and ready to go, finally.

I would recommend using the largest first approach for all of your uploads in the future, even though it means you'll have to know everything you want on the unit before starting. With fonts, I've found that just uploading a smaller file to any slot after a larger one has failed often causes the previous to work again; not sure if it will work in your case, but it may be worth a try.

As for a cause, I am actually working to make some units fail, which is a bit of a change for me. I'll get them over to our Engineering Supervisor once I've got a reproduceable failure so he can try to figure why this is happening.

When we've got some more info, I'll be sure to let you know.

~Troy

[Clark]

Hi Kevan,

I'm working on those failure examples today, and have been unable to duplicate the issues you have experienced using MOGD#.

If you could, please forward your images, and any special instructions, to myself at tclark@matrixorbital.ca.

Thanks,
~Troy