Ok - and thanks for your explanation.
"fs_tchproxy.dll" is only the Interface between GWES and touch driver. The active driver is under HKLM\Drivers\builtin\<boardname>\... , in the touch key where "flags"=dword:8 (dword:4 means "driver will not be load").
Nevertheless you cannot (and i would not recommend) delay a touch for 100ms within the driver. Why do you wan't to do this? Maybe we find an other solution for your purpose.
as already mention i would not address this resolved issues direct to your problem. And i see no possibility to fix this error without reproduce it in your office! I would prepare HW/SW so that i can measure line states/get further debug output. If you prepare cutable lines you may see if a slave helt the line(s) down in case of error.
>> Does the NI2C allocate memory in any form to do a Transfer?
<< No, but a Memory leak can be everywhere. Call "GlobalMemoryStatus" from time to time to check this
>> Updating the kernel in the field cannot be done
<< You can update kernel from OS: Update SW
But frist i would locate the probelem and test the solution.
you send me an email that this issue is resolved with the latest BETA kernel V1.40. Thanks for this.
PS: you can also refer our "changelog" for check resolved issues and our "roadmap" for check known issues. These files are located in the downloadarea for each board.
i would not address this issues direct to your problem. E.g. when you not explicite use/set repeated start/drive strength so it should have no effect. Nevertheless i woould test and update to the latest kernel.
Which problems do you have on I2C in detail?
these are exactly the same articles and we installed exactly the same SW. So i have no idea what happens here. Can you please send us the boards as RMA (via your distributor) with a detailed description. We will check RGB interface.
Can you please also write me an email with your connection list and registry.
Can you please provide me serial number of a "working" and a "non working" board.
don't think the problem is releated to HW V1.22 it was releasesd in 7/2013 and there are no changes concering LCD! Do you see this problem on more then one HW1.22.
What's about bootloader command XDE? Is it Y or N. Should be N.
>>same settings and do not work.
<< ok - but i have no idea were does this comes from?
What did you install at all?
Display driver setting?
PS: did you confirm "C" case sensitive?
1. are the bootloader and kernel versions the same on "new" and "old"?
2. you can reset the bootloader settings to factory default by bootloader command "C" - afterward you have to flash the kernel again!
Hope this helps.
sorry, i checked the code and saw the "boot read" is not implemented! Unfortunately the "help" for this command is implemente.
Because PV210 is EOL since many years we would not plan to implement this command.
As a workaroud you can read version of eboot from HKLM\Platform and you will find all eboots in our download area.
the registry should not be the problem. Which kernel version is installed and you are using the SKIT? So we will try to reproduce the Problem and investigate.
if link LED does not light it seems to be a HW problem. You should contact manufacturer of TD-10.
Note NetDCU8 and WCE50 are EOL!
did you recognized the "readme.txt" included into the zip? Here you will find the command line parameters (and keyboard input)!
So you can use e.g. the OS functions "CreateProcess" to start and control the ceplayit and "TerminateProcess" or "keybd_event" to termint ceplayit.
Hello, try another format e.g. wmv.
Any information on the serial debug line. Maybe codec is missung.
1. You may use a "pro" kernel in general this kernel contains MS Mediaplayer (or we can include it). You need pro license for this kernel! For access MP use MSDN online docs.
2. Try the attachment ceplayit
in the meanwhile i create a beta image with SNTP. You can download XIPVYB_C7E_V3.0_200420_BETA.
attached the driver and default sntp Registry. You may test if it works. Finally we will add it into the next release.
; @CESYSGEN IF SERVERS_MODULES_SNTPSVC
; "server" - FQDN of sntp server, or list thereof (REG_SZ or REG_MULTI_SZ). If not given, server-only operation assumed.
; "refresh" - period (in ms) between syncs with SNTP server. Ignored in server-only mode
; "recoveryrefresh" - time (in ms) to next sync if last attempt failed. Ignored in server-only mode
; "threshold" - interval (in sec) between time on SNTP server and current time when adjustment
; is allowed. If the difference between SNTP server time and local system time is bigger,
; update is ignored unless system clock is presumed incorrect (see below). Ignored in server-only mode
; "ServerRole" - if 1, enables server operation.
; "AutoUpdate" - if 1, enables automatic time updates by SNTP client. "server" must be specified.
; "trustlocalclock" - if 0, system is presumed to not have RTC capabilities. If this is the case,
; server multicast is disabled until clock sync with sntp server succeeds, and queries to the
; server return "unreliable clock" flag. Also, the time synchronization is forced on wake-up.
; If client is disabled, the clock is presumed trusted and this value is ignored
; "multicast" - dword of ipv4 address of multicast (deprecated; for compatibility only)
; or multi_sz of ipv4 and ipv6 multicast addreses. Default value below is for gateways.
; 22.214.171.124=all systems on the subnet
; 126.96.36.199=all NTP systems within router-defined scope
; FF02::1=all nodes on the link
; FF0X::101=NTP systems within site
; "multicast"=dword:010000e0 ; == 188.8.131.52
; "multicastperiod" - interval between subsequent multicasts.
; Every half-hour
; 1 day
which kernel/board you are using?
If HKLM\TimeSvc is not available I assume the DLL is also missing so that manually registering has no effect. So we can add SNTP into a future kernel *or* I can attach you the DLL into a next poat and we can try manually registering.
Please let me know.