CANBUS_EVENT_OVERRUN

    Hello


    At my NETDCU8 System I have from time to time the following on the serial debug interface:


    Code
    1. Data Abort: Thread=83e26000 Proc=80fee860 'device.exe'
    2. AKY=ffffffff PC=03844664(usbd.dll+0x00004664) RA=03842d78(usbd.dll+0x00002d78) BVA=06000f00 FSR=00000007
    3. Data Abort: Thread=83e26000 Proc=80fee860 'device.exe'
    4. AKY=ffffffff PC=03844664(usbd.dll+0x00004664) RA=03842ea0(usbd.dll+0x00002ea0) BVA=06000f00 FSR=00000007
    5. Data Abort: Thread=83e26000 Proc=80fee860 'device.exe'
    6. AKY=ffffffff PC=03844664(usbd.dll+0x00004664) RA=038437b0(usbd.dll+0x000037b0) BVA=06000f00 FSR=00000007
    9. CANBUS_EVENT_OVERRUN


    This means to me I miss a message from Can bus because Application could not take the message from the can driver fast enough.
    But I think the CANBUS_EVENT_OVERRUN is just a following error due to the data abort, but may be I am wrong.
    When I try analyse the Data Abort(look in remote processviewer ) I cannot find Thread=83e26000 and Proc=80fee860
    And what means AKY=ffffffff , usually here should be a Acces key number whit what I could look in remote processviewer.


    May be interesting, it does not seem to that anything is not working after this Data Abort, I can soft reset my machine, and everything works again.
    Could s.b. help my in the right way where I can start searching for the reason of this data abort? This Data Abort is an exception on driver level, correct?

    Hello,
    - do you run any program uses USB device? And does the problem disappear if the program is not started?
    - AKY=ffffffff -> excepting thread has access to all runnung processes(?)

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    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.


    bye

    Yes. Sending the error message to the serial debug port takes quite long. This happens with the priority of the USB driver which is rather high. In the meantime no drivers with lower priority can run. So if your CAN driver has lower priority (which is likely), then the CAN driver can not fetch data from the controller and the input buffer of the CAN controller may overrun.

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Interesting, the driver for my CAN is CANDRV.dll , I guess.


    Do you think, as a workaround, I may increase the priority of the receiving Thread of the driver with Priority256=dword:80 or lower, as described in another thread here?
    And does it make sense to decrease serialoutput priority, cause I do only use it for debugging.


    bye

    Quote from "andyinfsnet"

    Interesting, the driver for my CAN is CANDRV.dll , I guess.


    The name can be found in [HKLM\drivers\builtin\CID1].


    Quote

    Do you think, as a workaround, I may increase the priority of the receiving Thread of the driver with Priority256=dword:80 or lower, as described in another thread here?


    It may avoid the lost CAN messages. But it does not cure the USB problem.


    Quote

    And does it make sense to decrease serialoutput priority, cause I do only use it for debugging.


    No. The debug output can not be controlled by a driver setting. Sending a debug string simply stalls the current thread until the message is transmitted (busy wait loop). So if the thread has high priority, it will also stall all other threads with lower priority, including other driver threads. This is why drivers usually only output debug messages in case of an error.

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    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

    Actually you can use both. We try to keep the driver interface across different boards as similar as possible.


    The first document is the original documentation for NetDCU boards. This documentation only covers implementations with the SJA1000 CAN controller (like on NetDCU8), in other words driver V1.x. The second document is a little bit more general and basically handles all our boards, including implementations with SJA1000 and MCP2515 CAN controller. It is a little bit more targeted to the newer, improved versions V2.x that are currently only available for MCP2515 implementations, especially when talking of the concept of virtual send and receive ports. But the part that is available in V1.x is of course also covered. Also remember that V1.x is not fully thread-safe, i.e. calling the driver from different threads will only work correctly if you provide the synchronization within your own application.

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    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.

    Quote from "andyinfsnet"

    Is it possible to use the new driver 2.x on NETDCU8?


    This should be clear from what I have written already.

    Quote from "fs-support_HK"

    This documentation only covers implementations with the SJA1000 CAN controller (like on NetDCU8), in other words driver V1.x.
    [...]
    It is a little bit more targeted to the newer, improved versions V2.x that are currently only available for MCP2515 implementations


    In other words: No. We just do not have a backend for the SJA1000 in the V2.x driver yet, and it is also not on our current ToDo list. So unfortunately all SJA1000 boards have to stick with the V1.x driver. But if you are *really* interested in having a V2.x driver on the NetDCU8, then please contact <!-- e --><a href="mailto:sales@fs-net.de">sales@fs-net.de</a><!-- e --> to talk about implementing this backend.


    However synchronization is not very difficult in this case. Just create a global critical section object. Then in all the threads that call the CAN driver, just enter this critical section before the call to the driver and leave the critical section again when the call returns. By doing this you guarantee that only one thread is inside the driver at any time. If you want to use timeouts, use a Mutex instead of the critical section.

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    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):


    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.


    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.