none
CETK network tests RRS feed

  • Question

  • I want to use the CETK to test the WEC2013 device based on a Xilinx ZC702 board. The network card test is implemented in the ndt_1c.dll so I run the CETK test runner:

    tux -o -d ndt_1c.dll -c "-t GEMAC2" -l

    The first run is successful and outputs the list of test cases.

    NDT: CBinding: Max Pkt size of Miniport=1500
    03c600f2: ndt_1c Msg: Querying if miniport is wireless
    03c600f2: ndt_1c Msg: Miniport GEMAC2 is ** NOT Wireless-LAN **
    NDT:CBinding:DeallocatePools
    
    \ndt_1c.dll
    
       1: 1c_OpenClose
       2: 1c_Send
       3: 1c_LoopbackSend
       4: 1c_LoopbackStress
       5: 1c_SetMulticast
       6: 1c_Reset
       7: 1c_CancelSend
       8: 1c_FaultHandling
       9: 1c_OIDs
       10: 1c_64BitOIDs
       11: 1c_SuspendResume
       12: 1c_StressSusRes
       13: 1c_ResetOnResume

    When I repeat the same command line then the reult is always a failure.

    05420002: ndt_1c ERROR: Failed register the NDT test protocol driver (code 2404)
    05420002: ndt_1c ERROR: NDTStartup for 'GEMAC2' failed with hr=0x80070964
    05420002: ndt_1c ERROR: Failed close the NDT test protocol driver (code 6)
    05420002: ndt_1c ERROR: Failed deregister the NDT test protocol driver (code 1168)
    "\ndt_1c.dll" returned SPR_FAIL while handling the SPM_SHELL_INFO message.
    This DLL has been unloaded as requested.

    This does not change until I restart the device. It looks like the protocol driver NDT has been loaded by the first invocation of tux and has not been unloaded. Any further try to enumerate the test cases or even run a test fails until the device is reset. Is this the normal case for CETK?! How can one run a network test multiple times?


    • Edited by Harper23 Wednesday, December 21, 2016 3:09 PM
    Wednesday, December 21, 2016 3:08 PM

All replies

  • Hi Harper,

    If you think something is not getting unloaded, are you connected to remote tools or the debugger such that you can see what DLLs are still loaded?  Maybe that will help you identify what is stuck.

    Sincerely,

    IoTGirl


    Friday, December 23, 2016 4:02 AM
    Moderator
  • I used the command

    shell -c gi mod

    to identify the DLLs loaded before and after the test. The difference is that the ndt.dll is loaded after the list command. The matches somehow the message that the NDT protocol driver can't be loaded. I dont' be sure that the ndt.dll is the protocol driver but this would make sense.

    Further differences: The load count of following DLLs is increased:

    • k.coredll.dll
    • k.msvcrt.dll
    • ndis.dll

    Okay, now I have two symptoms. Maybe I have identified what's stuck. But I don't know why and how to avoid this.

    Is this the normal case for CETK?! How can one run a network test multiple times?

    Tuesday, December 27, 2016 11:18 AM
  • Hi Harper,

    I have done many long runtime tests using the CETK so my only thought is you have a test that is not completing/failing that is leaving the device in a bad state.

    Sincerely,

    IoTGirl

    Tuesday, December 27, 2016 4:48 PM
    Moderator
  • I can't confirm your thought but I can describe precisely what I've done.

    1. cold start of the device
    2. copy the CETK files to device using FTP (utilizing the other GEMAC adapter)
    3. run tux -l first time
    4. run tux -l second time

    So there is no test completed or failed that could cause the bad state. It was only a list command. Other tests run successfully from the CETK GUI.

    I must admit that neither the test nor the list command runs from the CETK GUI. The files that are transferred to the device are incomplete.

    I used the Dependency Viewer to identify the missing DLLs from the CETK\target folder and from the WINCE800\public\test folder, verified that all references are resolved. Then the files (DLLs, tux.exe) are copied to the device and tux.exe has been started.
    (The mentioned path names are not correct since I don't have access the workstation at the moment. They are only an idea of the source of the DLLs.)

    Regards,
    Harper

    Tuesday, December 27, 2016 8:54 PM
  • Hi Harper,

    Not sure I understand your topology. Normally CETK tests run and generate results of Pass/Fail so if you are not getting results I would say your tests are not completing so that is likely the source of the problem.

    Sincerely,

    IoTGirl

    • Marked as answer by Harper23 Thursday, December 29, 2016 1:42 PM
    • Unmarked as answer by Harper23 Thursday, December 29, 2016 1:42 PM
    Wednesday, December 28, 2016 5:20 PM
    Moderator
  • Not sure I understand your topology. Normally CETK tests run and generate results of Pass/Fail so if you are not getting results I would say your tests are not completing so that is likely the source of the problem.

    Let me clarify. I startet the device without any remainders of any test and copied the binaries from CETK to the device. I did not run any test.

    I know that CETK main task is to run test. Additionally there is at least one function of CETK that does NOT run a test but lists the test cases. I referred to this as the list command, probably not precise enough. But I hoped my command lines gave an example how this was meant.

    Does anybody has an idea why some CETK test are even impossible to list? These test DLLs don't access the test object as the Miniport driver that is addressed in this discussion. I have an evidence that no function of the Miniport has been called. I instrumented all functions with RETAILMSG and there was no output at all when "tux -l" has been invoked. I don't refer to any test case actually performed but only to the list of test cases.


    • Edited by Harper23 Thursday, December 29, 2016 2:35 PM
    Thursday, December 29, 2016 1:56 PM
  • Hi Harper,

    I would guess our lines are crossed.  How is the CETK connected to your device? Chances are networking is being used to facilitate that connection.

    Sincerely,

    IoTGirl

    Monday, January 2, 2017 11:09 PM
    Moderator
  • The CETK GUI is running at the PC. The test cases are running at the device. When I start the command

    tux -o -d ndt_1c.dll -c "-t GEMAC2" -l

    then there is no GUI used. I issue the command from the command prompt availabel through a Teklnet connection over Ethernet adapter GEMAC1.

    When I use the CETK GUI to run the tests then it utilizes the Ethernet adapter GEMAC1 too. Since the Zynq platform provides two Ethernet adapters it should be possible to test the second adapter while this first is used to control the test by Telnet or CETK GUI.


    • Edited by Harper23 Thursday, January 19, 2017 10:33 AM
    Thursday, January 19, 2017 8:01 AM
  • Hi Harper,

    Hmm,  I think I am still missing something in the topology but I know I was able to use one NIC for debug and the other for access in my old CEPC so I am curious if they are actually configured correctly.  When there is only one card, often the VMini bridge is used to support both debug and networking through one NIC. In your case you might want to shut this off but I am unclear as to how that would impact this test.

    Also, can you launch all of this with Platform Builder attached? Does that offer any insight?

    Sincerely,

    IoTGirl


    Thursday, January 19, 2017 5:07 PM
    Moderator
  • Hmm,  I think I am still missing something in the topology but I know I was able to use one NIC for debug and the other for access in my old CEPC so I am curious if they are actually configured correctly.

    Well there are two adapters and they are working as long as the CETK is not involved. So there is no reason to doubt if they are configured well, I hope. I also tried to communicate with the device through GEMAC2 and to test GEMAC1, this gave the same result.

    When there is only one card, often the VMini bridge is used to support

    Nope, no chance with cards. The Zynq has two Ethernet adapters in the silicon. No way to remove them, no need to to use something complicated like a virtual miniport on a KITL stack

    both debug and networking through one NIC. In your case you might want to shut this off

    Do I read "don't use KITL for this"? Well, I don't, because there are sufficient HW-resources.

    Also, can you launch all of this with Platform Builder attached? Does that offer any insight?

    No. There is the same behavior with Platform Builder connected.

    Thursday, January 19, 2017 8:58 PM
  • When you step through this through the PB connection, what does the debugger tell you is going on?  Are you in contact with the supplier of your BSP? Maybe they can help?
    Friday, January 20, 2017 8:05 PM
    Moderator