Posts by jopomo

    seems this happens basically when using CerHost remote display on current kernel WEC7 (beta included), however VNC seems to work with no such problem.
    Cerhost is unusable, can you verify it ?

    With armStone9r2 + kernel XIPIMX6_C7E_v210_160706.bin Ethernet connection is not working because we detected Cerhost disconnect periodically.
    Then now we are querying for pings continously to see response and many times the response is lost, and then, recover again and so on.
    Making exactly the same test (same computer and cable) to a different CPU like NetDCU14, ping command never fails, so it can be only a problem of armStone9r2 or its current kernel.
    Output debug is:
    ENET: LinkState: FULL-DUP, 100Mbps
    ENET: LinkState: FULL-DUP, 100Mbps
    ENET: LinkState: FULL-DUP, 100Mbps
    ENET: LinkState: FULL-DUP, 100Mbps
    According to your roadmap kernel, there are several bugs to solve on Ethernet, but it is almost unusable currently in this situation. Are you aware of this? or maybe anything else could be wrong ?

    With armStone9r2 and our application developped in C# .Net is showing bad background color on buttons created in windows forms.
    Seems the problem is similar (probably the same) to this tread:
    Background colors for buttons

    Using Set BtnOldSkin=1 in [HKEY_LOCAL_MACHINE\SYSTEM\GWE] does not work ... I guess the kernel image is not prepared for it (XIPIMX6_C7E_v210_160706.bin)
    Do you now about this error ?

    Note: we have not migrated application from VS2005+CF2 to VS2008+CF35 yet, but in any case application must work on WEC7 to my understand, instead, other functionalities of the application are working ok.

    You are right for USA , it changes if I set system time to Sunday 8 March 2015 1:59:00h AM, after 1 minute.... it changes to 3:00:00 AM but ONLY if CPU is powered on!
    When powered off, after booting system in a few minutes, time is not changed by OS ... dont not why. (same behaviour for DST Europe using instead last Sunday of March).

    We use last kernel v2.01 -march 5 2015 (based on you mean but with CF2) -> and according to this I have one more question: Why in the name of the kernel F&S use "v2.1" but in the FSBoardConfig panel from WinCE it says v2.01, is this right ?


    we experienced same issue that is described here, but with NetDCUA5:

    Change of Daylightsaving time during power off

    Using GMT+1, WinCE is able to change DST only if board is powered on, but does not change if it's powered off (after powering on again WinCE does not set any time as expected)
    On the other hand, if time is set to default Pacific GMT-8, then system time is not changed even with CPU powered on (dont know why, as to my knowledge in USA they use DST time too as in Europe).

    Any idea ?


    acording to changelog file of NetDCU_A5, a Nboot version v12 was released but I dont find it in download section:

    NBootVybrid - Change LogNBootVybrid - V12 (Released 2014-10-29)=======================================

    - 0002447: [NBoot] add serial number option for USB MSD download - resolved
    - 0002444: [NBoot] Change stack layout for more USR mode stack - resolved
    - 0002445: [NBoot] Change to new compiler - resolved
    - 0002449: [NBoot] enable NEON and VFP - resolved
    - 0002450: [NBoot] enable spread spectrum for all boards - resolved
    - 0002451: [NBoot] change initial memtest step size to 15 to detect more errors - resolved
    - 0002362: [Hardware] PCOMA5 minor HW rev update - resolved
    [7 issues]

    NBootVybrid - V11 (Released 2014-09-01)=======================================

    - 0002342: [NBoot] add external clock detection for enet phy's - resolved[1 issue]


    Can you uploaded this version ?

    Hello again,

    according to this issue, we have tried then the latest kernel for NetDCUA5 but WinCE6, not WEC7. Well, the problems occurs here too, so we have investigated a bit more.
    Then if we deploy our .Net app with CF2.0 to the CPU with VS2005 and check "Deploy the latest version of the .NET Compact Framework (including Service Packs)", then the problem does no occurs.!
    Maybe the problem is really on latest compact framework 3.5 version and not really on the windows CE itself (6 or 7) ?
    In this case, the problem for us is that F&S has not uploaded any WinCE6 kernel with CF2.0 included by default for NetDCUA5, only with CF3.5.
    So, can current v2.0 of WinCE6 kernel but with CF2.0 by defaul be compiled for NetDCUA5 and available on ftp ?

    Thank you for your appointments about "Align" and "MaskActive", I will investigate a bit more about this.
    However, I have never modified any of this register values for previous CPUs models we have used before.

    Let's suppose you have to program a simple CAN monitor that must be able to detect only if the message sniffed is type EXT or STD in a network where it is connected, and then show this property in a column. How do you do this whith
    NetDCUA5 + C# + dll CAN wrapper from F&S ? Would be necessary to prepare the register ? To my understand it would be only necesary to fix CAN baud rate to network rate, CommMask and Acceptancefilter in order to sniff any message in the bus... right?

    Let's suppose first problem is solved and we are able to receive in this sample any kind of CAN messages, one thing missing in the WinCE dll CAN wrapper from F&S is a flag indicating the type of CAN message received, while this is something present in others WIN32 API CAN dll for .Net,
    How can be distiguished if received message is EXT or STD with your WinCE .Net CAN wrapper?

    I will test it today again.
    Independent of our test application and our enviroment details, the reason of this post was that 2 weeks ago, the CAN driver of the NetDCUA5 was not able to transmiting EXT frames, and after new version, it's able of it.
    But, then our question is, using our application programmed in .Net and our network CAN enviroment, why using an older NetDCU10 we are able to receive both format frames without problems, and replacing it by a new NetDCUA5 executing exactly same .Net application (so using the CID1 CAN port configuration as described before) and using same network CAN enviroment, this CPU is not able to receive STD frames in this case only EXT. ?

    I have several questions:
    -Do you configure CAN port with CANCheck tool in any special way for supporting both kind of frames in reception?
    -Do you change this configuration for receiving i.e. EXT and then change again for receiving STD, or with an unique configuration flags you can receive both? (because changing configuration we are able to receive both too, but we need to receive both with a unique configuration of CAN port in order to distinguish which frame received is EXT and which one is STD).
    If it's not neccesary to reconfigure CAN port by CANCheck tool for receiving both EXT and STD, then we assume driver CAN is OK, but then we return to the beggining of our quetions:
    -CANCheck is not programmed with .NET and does not use F&S CAN wrapper dll, then the problem could be there...can you then try to use in a .Net project your CAN dll wrapper and try to see if with any combination of CAN flag configuration are you able to receive both kind of frames simultaneoulsy ??

    this will not solve the problem... we have this document from several years ago...
    The problem is very clear, with our configuration code (previous post) we are able to receive CAN frames in STD and in EXT format in the same network with CPUs like NetDCU10 and NetDCU14 (this one with some issues too).
    Then, executing same CAN configuration code on NetDCUA5, which CAN driver is recently working, it is not able to receive both kind of frames simultaneously.
    Can you try to reproduce this behaviour and see if there is any can driver problem yet for NetDCUA5 CPU, or tell us what can be wrong in the previous code configuration for not receiving both kind of CAN frames?

    testing again the CAN driver we see we are not able to receive STD and EXT frames from same CAN network. In this network there are devices which transmit EXT and another transmiting STD frames with same baudrate (100kbps), and NetDCU must be able to listen both on same CAN port.
    We are using .NET and dll CAN wrapper from F&S that we used previously with NetDCU10 and later with NetDCU14.
    Can you tell me how to configure in C# the CAN port to be able to receive both kind of frames ? or it's a driver problem yet ?
    We always configure the CAN port in this way with dll wrapper:

    pCAN1_CCS = new CanPort("CID1:", CanPort.CanAccess.READ_WRITE);
    pCAN1_CCS.ReadProperties(out CANprop1_CCS);

    //pCAN1_CCS.SetDefaultFrameFormat(CanPort.CanTransmitFormat.STANDARD); //11bits
    pCAN1_CCS.SetDefaultFrameFormat(CanPort.CanTransmitFormat.EXTENDED); //11 or 29 bits


    pCAN1_CCS.ReadAcceptanceFilter(out CANfilter1_CCS);
    CANfilter1_CCS.code = 0;
    CANfilter1_CCS.mask = 0xFFFFFFFF; //to allow all messages
    pCAN1_CCS.WriteAcceptanceFilter(ref CANfilter1_CCS);

    pCAN1_CCS.GetCommMask(out CANmask1_CCS);
    CANmask1_CCS = CanPort.CanEventFlags.CANBUS_ALL;


    Modifying bold lines we are able to receive STD or EXT in NetDCUA5, but never both simultaneouly.
    What can be done ??

    I have tried to rename dll and use without prefix "\FFSDISK\" and later with prefix again, and in both cases seems driver is not loaded.
    Its very strange, when I received the CAN dll file for the other CPU ArmStoneA9/WCE7 it worked inmediatly only modifying the path in the register.
    I dont know why same procedure does not work here.
    One solution is to release a WinCE 6 beta kernel for NetDCUA5 with this driver inside in the next days.
    The current WinCE6 core kernel is including CF3.5, will be a kernel release for this CPU including CF2.0 ?

    with default driver, in serial debug appears:
    CID: Version 2.4, ActiveKey = Drivers\Active\19
    CID: Version 2.4, ActiveKey = Drivers\Active\20

    But when I point to the new driver in \FSSDISK\ in the register and then reboot, none of this 2 lines about CID appears ... seems the new CAN driver is not loaded...I dont know why (no spelling errors).