>> It should not related to the BSP. Assume if you use same catalog and project settings as for A9X it should behave in the same way on A9XR2.
That is what I expected as well. I suppose it is related to some configuration setting, but what, where, I don't know. I have used BSP that you provided, but I have kept catalog (FSiMX6SX.pbxml) and project settings from efusA9X project.
Hello,
<< I can't believe this. The only difference between A9X and A9XR2 is the Ethernet phy!
Yes, I believe you, the only difference in hardware, but for software, I am not sure. Anyway, I have found the workaround, and I will definitely consider your suggestion as well.
Concerning SD card issue, please forget it. It turned out to be hardware fault. I have tried it on a different device and SD card plug&play works as expected.
Best regards,
Vladimir
Dear Support Team,
For registry:
Term "auto reg flush feature" is probably wrong. I have found the following information in WEC7 documentation:
Flush-On-Close Registry Flush
The Windows Embedded Compact OS run-time image can be confi gured to fl ush the registry
automatically by setting the following registry:
[HKEY_LOCAL_MACHINE\init\BootVars]
“RegistryFlags”=dword:1
Flush-on-close is also referred to as Aggressive Flushing in some documentation for the earlier
version of Windows Embedded Compact. When this feature is enabled, it can cause performance
degradation.
This is what I did for efusA9XR2 to get the same behaviour as on efusA9X (since we did not use explicit RegFlushKey() on efusA9X either and registry persisted). I wonder why did I have to do this for efusA9XR2. It seems to me that Flush-On-Close feature is not dangerous, since our registry modifications are rather rare. Anyway, we had no issues on efusA9X regarding FAT by now.
For SD:
Pins that we use for SD match SD_B port on efus.
Best regards,
Vladimir
I have made the following modification in my OSDesign.reg:
; HIVE BOOT SECTION
[HKEY_LOCAL_MACHINE\init\BootVars]
"SYSTEMHIVE"="\\Registry\\system.hv"
"PROFILEDIR"="\\Registry"
"Flags"=dword:3
"DefaultUser"="User"
"RegistryFlags"=dword:1
; END HIVE BOOT SECTION
And I got back persistent registry feature. Please tell me if these are safe and correct settings and why did I have to use them.
Best regards,
Vladimir
Dear Support Team,
Concerning persistent registry issue, I have noticed that if I make change in registry and call "reg save" from ndcucfg, then my modification is persisted after reboot. How do I enable auto reg flush feature? Maybe with this setting:
[HKEY_LOCAL_MACHINE\init\BootVars]
"RegistryFlags"=dword:1
Best regards,
Vladimir
Dear Support Team,
I have finally received efusA9XR2 samples and started playing with the BSP you have provided. Currently, I am facing two issues (which obviously were not present on efusA9X):
1) My registry modifications are not permanent, ie. they are lost after reboot. This is the major issue. My registry is hive based and system.hv is located in the root of NANDFlash.
2) SD card is not plug&play: if you remove it, it is still shown in the system, but normally, you cannot access access files on it. If you reinsert the card, nothing happens. You have to reboot the device in order to make it work again. This issue is minor one for now.
Best regards,
Vladimir
Dear Support Team,
I have found the problem, so please neglect this thread. The issue was in initialisation commands set under:
[HKEY_LOCAL_MACHINE\Drivers\Unimodem\Settings]
One of the commands specified here was not supported by Quectel EG91 and modem returned ERROR on it. Dial up application would then fail, but unfortunately with misguiding error message that serial port is not available.
Sorry for disturbance.
Best regards,
Vladimir
One more note: when I take COM port with my terminal application, then dial up application exits immediately. When COM port is free, then dial up takes some time (3-5 seconds) before exiting with the before mentioned error.
Best regards,
Vladimir
Dear Support Team,
I have issues with GPRS dial up connection. It simply fails to open specified COM1 (UART6 in my case) port although port is certainly not used by other applications:
I have simple terminal application which I use send AT commands on COM1 port and it works without issues, so I confirm that GSM module works, and COM1 works (GSM module answers to AT commands, registers on network and I can even make GPRS connection using AT commands).
Do you have an idea what could be the problem? Maybe Windows CE dial up monitors some UART line and falsely concludes that port is occupied based on its level?
PS I have this issue after we changed GSM module attached on COM1. Previously we have used Telit GL865 and dial up worked normally. We are now trying to put Quectel EG91 in use, but the problem with dial up occurred.
Best regards,
Vladimir
Dear Support Team,
Thanks for the feedback. I have just returned from the vacation. As soon as I manage to test your patch, I'll let you know the results.
Best regards,
Vladimir
No problem, I will wait for the patch. I tried to copy DLLs manually to the device, but starting SFTP server failed because it could not load all the required DLLs.
Hmmm, I am not sure we understand each other. There is no purpose in changing registry when there are no DLLs to support SSH in the image. And I cannot add DLLs to the image because I cannot select required items in the catalog view when creating image. So the initial problem is how to override red x marks from the screenshot in the first post.
Best regards,
Vladimir
Hello,
Thanks for the feedback.
Just as a note, I see SSHD.DLL and SFTP-SERVER.EXE files under C:\WINCE700\platform\FSIMX6SX\Prebuilt\platcomm. I am not sure if this means that DLLs are already in the BSP but the problem is elsewhere.
Best regards,
Vladimir
Dear Support Team,
Can you please advise me how to enable support for SSH and SFTP server? I've tried to add it through catalog items in platform builder under SSH-SSL-SMTP node, but they keep getting excluded from image because of some platform settings:
I could not find SSH/SFTP mentioned in the documentation. What registry settings are used?
Thanks in advance.
Best regards,
Vladimir
Dear Support Team,
Ok, thanks. Can you please tell me when do you expect to have EFUSA9Xr2-V2-W13 available for buyers (with at least Ethernet driver)?
Best regards,
Vladimir
Dear Support Team,
We are about to order new quantities of EFUSA9X-V2-W13. Can you please tell me what is the difference in hardware and software between EFUSA9Xr2-V2-W13 and EFUSA9X-V2-W13?
I understand that you have introduced r2 because of Ethernet PHY supply issues. From our point of view, I expect modifications in BSP which would support new hardware. Am I right? Would we be able to support EFUSA9X and EFUSA9Xr2 with the same firmware?
Best regards,
Vladimir
Hello,
I also don't have an idea how RTS change could be delayed for so long while priority is 99, but this seems to happen. Since this happens pretty rarely, and since we have no further ideas what to do, I've decided to give up this kind of testing and to implement current solution (RTS_CONTROL_TOGGLE + thread priority 99) into our device firmware and try real life RS485 communication. And indeed, situation seems promising, I haven't observed communication errors during tests in the past few days.
Basically, it seems we have good enough solution, so I want to thank you once again for all the help and support. If you, by any chance, come to some new information about this problem, you can share it with me.
Best regards,
Vladimir Obradovic
Sorry for confusion. I'll try to be more precise. Here are my test cases and results from Friday and today.
1) Test case from Friday. Settings:
- original csp_serial.dll used
- CeSetTreadPriority(GetCurrentThread(), 99);
- Priority256 not used
Result: about 100k messages exchanged. Zero bytes read when error occurred.
2) Test case from today. Settings:
- your csp_serial.dll used
- CeSetTreadPriority(GetCurrentThread(), 104);
- Priority256 not used
Result: about 50k messages exchanged. Zero bytes read when error occurred.
I will test whatever you propose.
Thanks for your efforts.
Hello,
I have done some tests with setting priority of read/write thread to 104 and not using Priority256. Stability is better. I can exchange more than 50k messages before error. And now, when error occurs, 0 bytes is read, meaning that RTS delay is such long that all receiving message is masked. Here is output on efus side when error occurred:
33, 0, *** Message #54977 from PC! ***
33, 0, *** Message #54978 from PC! ***
33, 0, *** Message #54979 from PC! ***
33, 0, *** Message #54980 from PC! ***
0, 0, \sdcard>
You can find attached source code of test applications I have used. Maybe you can try it yourself. I think you can use RS232 if you don't have RS485.
I am sorry, I still don't get what you want to say...
>> But if you in hurry it makes no sense e.g. to call ReadFile with prioritiy 251 or only decrease Priority256 below 103. In this case I would call ReadFile and following actions with priority 104 (most important read data from HW (103) than process data (104)).
<< I don't understand this sentence(s). Both reading and writing on UART is done in a single thread, first we read data from UART, if it is what we expect, then we write some data, and then continue loop with reading. So, if we don't set Priority256 registry value, then the DispatchThread has priority 103. If we set priority of our read/write application thread to 104, then our application could be delayed (by whatever interrupt) to drive RTS on time after serial driver has finished with sending data. Right?
>> Assume it is another reason. Because here we have a handshake and our partner will nothing send as long as RTS is not clear.
Do you have this problem only while connect or also while normal modem operation?
<< Ok, thanks. I am still investigating this issue. It happens that during normal modem operation, dial up connection gets broken, but our software does not get notified on this (software is based on .NET compact framework).
