Using the latest driver version for EG20T UART under Windows Embedded Standard 2009, I've noticed the UART is transmitting something on system boot (driver load?). This in turn causes an error when my application starts communicating with the peripheral device (as it already has something in the input buffer).
Did anyone see this phenomenon?
Anyway around this?
Please provide the following information:
1. Have you experienced this issue on another OS?
2. Which drivers are you using?
3. Could you please tell me which processor you're using, and also the s-spec number?
Thanks for picking this up.
1. I did not have any other OS on that hardware, however, jugging from the timing of the phenomenon, I can conclude it's not caused by hardware. On old hardware we were running under Windows CE and all was fine.
2. I'm using:
Intel(R) Platform Controller Hub EG20T Drivers
For Windows XP* and Windows Embedded POS Ready
Copyright (c) 2013, Intel Corporation and/or its suppliers and licensors. All rights reserved.
3. The processor is Atom E680. What's "s-spec number" ?
Hi, Ely. While Jimmy is checking into your problem I thought that I'd point out that the Atom E680 and the EG20T are Intel's http://www.intel.com/content/www/us/en/intelligent-systems/queens-bay/embedded-intel-atom-e6xx-serie... Queens Bay platform. Here is thehttp://www.intel.com/content/dam/www/public/us/en/documents/datasheets/platform-controller-hub-eg20t... datasheet to the EG20T. Hope this is helpful. LynnZ
Thanks for your reply.
I recommend you this guide:
http://www.intel.com/support/processors/sb/CS-031392.htm Product Specifications and Comparisons: How to Find Your sSpec Number
We'll continue looking into this issue and as soon as we have more information, we'll get back you.
Thanks for the input rosswatanabe, good suggestion.
I do not have access to the processor or it's packaging.
I'm using a ready made hardware and the processor is buried under a screwed on heat-sink.
is that information really critical for fixing an issue with a driver that handles another IC?
Are you sure the issue is the driver and not the BIOS? You can determine this by booting DOS.
A quick work around for this issue would be to clear the peripherals input buffer on start up.
Thanks for the suggestions Ross.
Yes, I'm pretty sure it's not the BIOS.
The peripheral devices are already turned on when the computer boots.
I can not modify their firmware and modifying my application to clear the start-up error is an obvious work-around but not the best solution.
Still hopping for a driver fix...
I requested the s-spec number in order to gather the most information possible. For the time being it's OK, if we do need it I'll request it again.
Can you confirm the suggestion, that was provided by rosswatanabe, about flushing the buffers after boot?
Are you able to reproduce this issue on another OS?
We're currently looking for a previous version of the driver, so that we can try to rule out a driver issue.
We have also consulted with the next level of support on this case. we'll keep you updated and let you know any new information.
Already replied to that suggestion - can not be done (can not modify peripheral device firmware).
Another OS means another driver... Results there will not mean anything.
Anyway, no - I can not test with another OS.
I tend to believe it's a driver issue... Can you reproduce it with the same driver version?
What testing can you do?
we continue to work on this issue, we're trying to set up a test for your case. We'll get back to you as soon as we have results.
In the meantime I have sent to your e-mail a previous version of this driver, V2.4.1. Could you try using this driver and lets us know if the same issue occurs.
We would like to know if you were able to try the driver?
Did you have any positive results?
Please let us know your comments.
As it turned out, mostly, one particular device was sensitive to this phenomenon. Not all of them...
I have incorporated a mechanism in my application to enable me to ignore any errors, following power on, from devices while making sure they do not lose the first meaningful command being sent to them.
This code patch has been tested and was just approved by our customer.
Thanks for your reply.
Please do not hesitate to let us know if there is something else that we can help you with.