Posts by andyinfsnet

    For better explanation what I mean, under .net CLR, I try to send a bunch of bytes from NETDCU8 (serially / COM3 / 115200bd), when the bytes are transmitted I see this output on the serial debug interface:
    WAIT- for 0x417a5722, mask 0x00000004
    WAIT+ for 0x417a5722, mask 0x00000004


    The bytes are transmitted correctly(port sniffed), only I think this debug output is unusual, may be it is even decreasing performance of the Netdcu8.
    Probably it has to do with IOCTL_SERIAL_WAIT_ON_MASK, from the native API, but how to understand and avoid it?


    I use from OpenNETCF.IO.Serial the property : public byte[] Output { set; } to deliver the bytes to the serial interface.
    Please have a look.

    Hello


    I use serial communication in netdcu8, does anyone know what this output means(from debug serial interface):


    WAIT+ for 0x61489266, mask 0x00000003
    WAIT- for 0x61489266, mask 0x00000003
    WAIT+ for 0x61489266, mask 0x00000083
    WAIT- for 0x61489266, mask 0x00000002
    WAIT+ for 0x61489266, mask 0x00000004
    WAIT- for 0x61489266, mask 0x00000004

    Hello


    I have PicoCOM4 Hardware revision 1.2 and want to use CAN Bus from PicoCOM4.
    Usually I initalize like this
    m_hCAN = CreateFile(pszName, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL );
    When doing so GetLastError() returns 55
    Looks, thed driver is not available, can you help here?


    The serial debug output looks like this:


    Hello, just a short question
    Is it possible to have / enable RS485 interface on the NETDCU8 ?
    What would I need to do? Are there drivers availabe?

    Hello,


    1. so you mean the calibration algorythm will not handle calibration together with this serial debug output, due to timing problems ?
    2. You don´t think that one of the four wires was bad connected before shorten the flat ribbon(I mean the numbers make no sense to me, compared to the "good cal." numbers)?


    I will try to increase the MaxCalError when I will have problems next time.

    Just a question, I had small trouble while calibrating a TX14D14 touch. The calibration gives me following values, but it never stopped:


    TCHPDD: DOWN: TSP_GetXY(1019, 513)
    TCHPDD: Move: TSP_GetXY(1020, 511)
    TCHPDD: Move: TSP_GetXY(1021, 510)
    TCHPDD: Move: TSP_GetXY(1020, 514)
    TCHPDD: Move: TSP_GetXY(1020, 514)
    TCHPDD: Move: TSP_GetXY(1019, 515)
    TCHPDD: Move: TSP_GetXY(1020, 510)
    TCHPDD: Move: TSP_GetXY(1021, 514)
    TCHPDD: Move: TSP_GetXY(1021, 516)
    TCHPDD: Move: TSP_GetXY(1021, 508)
    TCHPDD: Move: TSP_GetXY(1020, 516)
    TCHPDD: UP: TSP_GetXY(1020, 516)
    TCHPDD: DOWN: TSP_GetXY(1021, 856)
    TCHPDD: Move: TSP_GetXY(1020, 857)
    TCHPDD: UP: TSP_GetXY(1020, 857)
    TCHPDD: DOWN: TSP_GetXY(1019, 855)
    TCHPDD: Move: TSP_GetXY(1021, 857)
    TCHPDD: Move: TSP_GetXY(1021, 856)
    TCHPDD: Move: TSP_GetXY(1021, 856)
    TCHPDD: Move: TSP_GetXY(1021, 852)
    TCHPDD: Move: TSP_GetXY(1020, 850)
    TCHPDD: Move: TSP_GetXY(1019, 854)
    TCHPDD: Move: TSP_GetXY(1019, 857)
    TCHPDD: Move: TSP_GetXY(1020, 853)
    TCHPDD: Move: TSP_GetXY(1020, 858)
    TCHPDD: Move: TSP_GetXY(624, 78)
    TCHPDD: UP: TSP_GetXY(624, 78)
    TCHPDD: DOWN: TSP_GetXY(1020, 850)
    TCHPDD: Move: TSP_GetXY(1021, 858)
    TCHPDD: Move: TSP_GetXY(1020, 856)
    TCHPDD: Move: TSP_GetXY(1021, 858)
    TCHPDD: Move: TSP_GetXY(1020, 858)
    TCHPDD: Move: TSP_GetXY(1020, 862)
    TCHPDD: Move: TSP_GetXY(1021, 857)
    TCHPDD: Move: TSP_GetXY(1022, 855)
    TCHPDD: Move: TSP_GetXY(1021, 850)
    TCHPDD: Move: TSP_GetXY(1018, 858)
    TCHPDD: Move: TSP_GetXY(1019, 854)
    TCHPDD: Move: TSP_GetXY(1021, 851)
    TCHPDD: Move: TSP_GetXY(1018, 855)
    TCHPDD: UP: TSP_GetXY(1018, 855)
    TCHPDD: DOWN: TSP_GetXY(1021, 165)
    TCHPDD: Move: TSP_GetXY(1021, 164)
    TCHPDD: Move: TSP_GetXY(1020, 165)
    TCHPDD: Move: TSP_GetXY(1017, 162)
    TCHPDD: Move: TSP_GetXY(1020, 164)
    TCHPDD: Move: TSP_GetXY(1020, 160)
    TCHPDD: Move: TSP_GetXY(1020, 164)
    TCHPDD: Move: TSP_GetXY(1021, 160)
    TCHPDD: Move: TSP_GetXY(1020, 163)
    TCHPDD: Move: TSP_GetXY(1021, 169)
    TCHPDD: Move: TSP_GetXY(1020, 163)
    TCHPDD: Move: TSP_GetXY(1021, 160)
    TCHPDD: UP: TSP_GetXY(1021, 160)
    TCHPDD: DOWN: TSP_GetXY(1022, 171)
    TCHPDD: Move: TSP_GetXY(1020, 164)
    TCHPDD: Move: TSP_GetXY(1019, 172)
    TCHPDD: Move: TSP_GetXY(1019, 171)
    TCHPDD: Move: TSP_GetXY(1020, 168)
    TCHPDD: Move: TSP_GetXY(1021, 170)
    TCHPDD: Move: TSP_GetXY(1017, 165)
    TCHPDD: Move: TSP_GetXY(1020, 167)
    TCHPDD: UP: TSP_GetXY(1020, 167)
    TCHPDD: DOWN: TSP_GetXY(1019, 169)
    TCHPDD: Move: TSP_GetXY(1021, 162)
    TCHPDD: Move: TSP_GetXY(1021, 164)
    TCHPDD: Move: TSP_GetXY(1017, 168)
    TCHPDD: Move: TSP_GetXY(1021, 165)
    TCHPDD: Move: TSP_GetXY(1019, 169)
    TCHPDD: Move: TSP_GetXY(1022, 165)
    TCHPDD: Move: TSP_GetXY(1021, 168)
    TCHPDD: Move: TSP_GetXY(1021, 167)
    TCHPDD: Move: TSP_GetXY(1021, 165)
    TCHPDD: Move: TSP_GetXY(1021, 165)
    TCHPDD: UP: TSP_GetXY(1021, 165)


    After shortening the 4 wires to minimum(lets say it are now 5cm instead 10cm) the calibration worked, giving me following values:


    TCHPDD: DOWN: TSP_GetXY(504, 507)
    TCHPDD: Move: TSP_GetXY(506, 508)
    TCHPDD: Move: TSP_GetXY(505, 506)
    TCHPDD: Move: TSP_GetXY(504, 506)
    TCHPDD: Move: TSP_GetXY(506, 508)
    TCHPDD: Move: TSP_GetXY(504, 512)
    TCHPDD: Move: TSP_GetXY(504, 514)
    TCHPDD: Move: TSP_GetXY(504, 513)
    TCHPDD: Move: TSP_GetXY(506, 514)
    TCHPDD: Move: TSP_GetXY(506, 508)
    TCHPDD: Move: TSP_GetXY(503, 509)
    TCHPDD: UP: TSP_GetXY(503, 509)
    TCHPDD: DOWN: TSP_GetXY(164, 850)
    TCHPDD: Move: TSP_GetXY(163, 854)
    TCHPDD: Move: TSP_GetXY(163, 859)
    TCHPDD: Move: TSP_GetXY(163, 856)
    TCHPDD: Move: TSP_GetXY(163, 858)
    TCHPDD: Move: TSP_GetXY(165, 854)
    TCHPDD: Move: TSP_GetXY(165, 858)
    TCHPDD: UP: TSP_GetXY(165, 858)
    TCHPDD: DOWN: TSP_GetXY(168, 853)
    TCHPDD: Move: TSP_GetXY(167, 853)
    TCHPDD: Move: TSP_GetXY(166, 855)
    TCHPDD: Move: TSP_GetXY(166, 856)
    TCHPDD: Move: TSP_GetXY(167, 857)
    TCHPDD: Move: TSP_GetXY(166, 856)
    TCHPDD: Move: TSP_GetXY(165, 856)
    TCHPDD: Move: TSP_GetXY(166, 855)
    TCHPDD: Move: TSP_GetXY(167, 850)
    TCHPDD: Move: TSP_GetXY(167, 856)
    TCHPDD: Move: TSP_GetXY(165, 855)
    TCHPDD: Move: TSP_GetXY(165, 852)
    TCHPDD: Move: TSP_GetXY(165, 848)
    TCHPDD: Move: TSP_GetXY(167, 851)
    TCHPDD: Move: TSP_GetXY(168, 852)
    TCHPDD: Move: TSP_GetXY(166, 850)
    TCHPDD: UP: TSP_GetXY(166, 850)
    TCHPDD: DOWN: TSP_GetXY(833, 852)
    TCHPDD: Move: TSP_GetXY(835, 857)
    TCHPDD: Move: TSP_GetXY(835, 857)
    TCHPDD: Move: TSP_GetXY(834, 860)
    TCHPDD: Move: TSP_GetXY(834, 858)
    TCHPDD: Move: TSP_GetXY(834, 864)
    TCHPDD: Move: TSP_GetXY(836, 862)
    TCHPDD: Move: TSP_GetXY(835, 860)
    TCHPDD: Move: TSP_GetXY(836, 860)
    TCHPDD: Move: TSP_GetXY(838, 859)
    TCHPDD: Move: TSP_GetXY(839, 859)
    TCHPDD: Move: TSP_GetXY(840, 858)
    TCHPDD: Move: TSP_GetXY(842, 854)
    TCHPDD: Move: TSP_GetXY(843, 857)
    TCHPDD: Move: TSP_GetXY(840, 854)
    TCHPDD: UP: TSP_GetXY(840, 854)
    TCHPDD: DOWN: TSP_GetXY(845, 177)
    TCHPDD: Move: TSP_GetXY(843, 169)
    TCHPDD: Move: TSP_GetXY(842, 170)
    TCHPDD: Move: TSP_GetXY(842, 170)
    TCHPDD: Move: TSP_GetXY(843, 168)
    TCHPDD: Move: TSP_GetXY(846, 168)
    TCHPDD: Move: TSP_GetXY(848, 163)
    TCHPDD: UP: TSP_GetXY(848, 163)
    TCHPDD: DOWN: TSP_GetXY(847, 171)
    TCHPDD: Move: TSP_GetXY(844, 167)
    TCHPDD: Move: TSP_GetXY(843, 164)
    TCHPDD: Move: TSP_GetXY(844, 163)
    TCHPDD: Move: TSP_GetXY(845, 164)
    TCHPDD: Move: TSP_GetXY(847, 163)
    TCHPDD: Move: TSP_GetXY(848, 164)
    TCHPDD: Move: TSP_GetXY(849, 164)
    TCHPDD: UP: TSP_GetXY(849, 164)
    TCHPDD: DOWN: TSP_GetXY(854, 161)
    TCHPDD: Move: TSP_GetXY(855, 164)
    TCHPDD: Move: TSP_GetXY(854, 162)
    TCHPDD: Move: TSP_GetXY(853, 163)
    TCHPDD: Move: TSP_GetXY(852, 160)
    TCHPDD: Move: TSP_GetXY(852, 161)
    TCHPDD: Move: TSP_GetXY(851, 162)
    TCHPDD: Move: TSP_GetXY(851, 163)
    TCHPDD: Move: TSP_GetXY(851, 163)
    TCHPDD: Move: TSP_GetXY(852, 160)
    TCHPDD: Move: TSP_GetXY(852, 161)
    TCHPDD: Move: TSP_GetXY(853, 161)
    TCHPDD: Move: TSP_GetXY(853, 165)
    TCHPDD: Move: TSP_GetXY(852, 166)
    TCHPDD: UP: TSP_GetXY(852, 166)
    TCHPDD: DOWN: TSP_GetXY(162, 168)
    TCHPDD: Move: TSP_GetXY(161, 168)
    TCHPDD: Move: TSP_GetXY(160, 164)
    TCHPDD: Move: TSP_GetXY(160, 165)
    TCHPDD: Move: TSP_GetXY(162, 163)
    TCHPDD: Move: TSP_GetXY(163, 166)
    TCHPDD: Move: TSP_GetXY(163, 163)
    TCHPDD: Move: TSP_GetXY(163, 168)
    TCHPDD: Move: TSP_GetXY(165, 167)
    TCHPDD: Move: TSP_GetXY(167, 164)
    TCHPDD: Move: TSP_GetXY(166, 170)
    TCHPDD: Move: TSP_GetXY(169, 170)
    TCHPDD: Move: TSP_GetXY(168, 176)
    TCHPDD: Move: TSP_GetXY(167, 169)
    TCHPDD: UP: TSP_GetXY(167, 169)
    TCHPDD: DOWN: TSP_GetXY(500, 518)
    TCHPDD: Move: TSP_GetXY(508, 516)
    TCHPDD: UP: TSP_GetXY(508, 516)
    so the reason can be to long cable or bad contacted pins on the flat ribbon 10 pin connector.
    What do you think when you read these numbers?

    I found now the reason for unexpected closing. With a remote tool (NetCFLogging.exe, from the powertoys set) I could log that it(probably Windows itself) is out of memory. Windows CE seems to be allowed to close application in this case without explicit warning.
    (Although I have already seen such OOM warnings on the screen in other cases, when I had bad software design and the volatile memory was insufficient). Ok I do not know the reason why this is not displayed in ths certain case but anyhow, the more strange thing is that my application runs without any problem and with some MB reserve in memory, as long as I do not press any button in the Windows task bar, let´s say the "Start" button. Then the appplication stops(or let´s say disappears) with a logged string "OutOfMemory".


    Has anyone an comment how this can be? I always thought that Windows is protected against any "bad" application, but never knew that I need to protect my app against windows. Do you have another idea?

    This info seems to have helped me(where can I get such map files?). I did some change in LocalFree(), what seems corresponding to your mentioned RHeapFree (is this true?) and the messages disappeared. Unfortunately the problem that the application stops is not gone.
    But what I have seen, when disabling one debug message in my code (Debug.WriteLine("yxz...")) the problem now arrives more often, and additionally, what was not before, there are new system messages, when deploying and starting the application:
    ETH: TX UNDERRUN
    ETH: Error Overrun
    ETH: TX UNDERRUN
    After program start(and do not hit a button) these messages do not arrive anymore.
    By the way I use now a Picocom2(herefore I have a user kernel) and nomore a Picocom4.


    Any help appreciated.

    I do not use random numbers.


    Can you not say anything about this? ->>


    Exception 'Data Abort' (4): Thread-Id=05e6009e(pth=83dfc6c0), Proc-Id=050f007e(pprc=831b673c) 'Application.exe', VM-active=050f007e(pprc=831b673c) 'Application.exe' PC=400302c0(coredll.dll+0x000202c0) RA=00040000(???+0x00040000) SP=0071fc2c, BVA=00b40018


    Is there no way to use this information to start a basic narrowing? If I use iterative narrowing, don´t know how long this would take.

    I have a problem and have no further ideas what to do. May be you can give some remarks. The application I am talking about is in written in C# and is using p/invokes a lot. It is talking with another application via UDP over the ethernet. It is running on a PICOCOM4 WCE6.0R3 with Kernel NKPC4_PRO_CF35_111123


    Application runs as it should, as long as I want without problems, but when I am using the windows taskbar, let´s say to switch from application to a control panel, or whatever, then it happens from time to time, let´s say every 50th button pressing, that the application stops without any exeption or any warning, like if I would really close the program. I checked sources already if it would be a unwanted program stop, but there is nothing like that(actually the program never needs to stop)


    Beside this behaviour there is, from time to time and with no relation to any interaction, some output on the debug interface:


    +OALIoCtlHalGetHWEntropy
    +OALIoCtlHalGetHWEntropy


    Exception 'Data Abort' (4): Thread-Id=05e6009e(pth=83dfc6c0), Proc-Id=050f007e(pprc=831b673c) 'Application.exe', VM-active=050f007e(pprc=831b673c) 'Application.exe' PC=400302c0(coredll.dll+0x000202c0) RA=00040000(???+0x00040000) SP=0071fc2c, BVA=00b40018


    No idea what that means but feeling says this is related to my attached problem. When I debug with Visual studio via Ethernet connection, and the application is stopping, there comes the messages that the connection to the device is broken, as if one unplugs the Ethernet connection. When I run the application (started from device), and the application is stopping, it just stops and the window disappears. I already activated all exceptions in Visual studio, but nothing happens. Is there anything I can do to find this ?

    Quote from "andyinfsnet"


    Yes I use a second ethernet adapter, this one is via USB. I will check if the error occurs only in the case when this interface / driver is used.
    I wonder why this dll has access to all other proces, may be bad driver implementation.


    Just the promised info: I tested overnight without this second ethernet adapter and no such exceptions happened. So I know the guilty part but have no solution.

    Another issue happend this overnight test. There has been a DM9CE: DriverReset
    Can you tell me what you know about this DM9CE DriverReset? In which condition does this happen?
    Can this have relation to the usbd.dll. exceptions? And furthermore, is there a way to debug this usbd.dll?
    May be I can find more information why this exception happens.


    Yes it should have been clear, sorry. Because I am not so perfectly sure in synchronising, could you please check if following sync is enough, when calling this method (CCAN::Write) from different threads (and having declared the cs_CanBusWriting globally):


    Is it possible to use the new driver 2.x on NETDCU8? Seems I have 1.02 only(readout from IOCTL_CAN_READ_PROPERTIES).
    Over the time the synchronisation made from you would be probably safer than from our Application.
    CAN is builtin driver so new kernel would be necessary, I guess. We already have a user kernel.

    Hello just a question, on a NETDCU8 is this
    <!-- m --><a class="postlink" href="http://www.fs-net.de/download/docu/netdcu/english/WINCE_CAN_INTF_eng.pdf">http://www.fs-net.de/download/docu/netd ... TF_eng.pdf</a><!-- m -->
    or this
    <!-- m --><a class="postlink" href="http://www.fs-net.de/download/docu/picocom/english/WINCE_CanInterface_eng.pdf">http://www.fs-net.de/download/docu/pico ... ce_eng.pdf</a><!-- m -->
    the relevant driver information ? I am a bit confused what to use because WINCE_CanInterface_eng.pdf is for PICOCOM usually, biut the name of the driver
    Candrv.dll is mentioned in my NETDCU8 registry under hklm/drivers/builtin/CAN1


    thanks