DK-S7G2M: Initialization of USB-Mass-Storage-Device kills Network

Hi,

I have an application where a webserver and an USB-mass-storage-device should share the access to a MMC-filesystem. Both modules separate works fine. I can access files via the webserver or via the USB-interface if I initialize only one of them.
But if I initialize the USB-device, the network goes dead. No ping response and no connection to the webserver furthermore. The USB-device works normal at this point.
I attached a stripped version of my project, where the network is initialized immediately but the USB-device after 20 seconds. Within this twenty seconds the network-access is functional, after initialization of the USB after 20 seconds the network goes down.
I hope that someone can find my failure and help to bring both modules work together.

A second question. In this application I need a second USB-mass-storage-device (applicated as second drive on the PC). What have I to do to create two independent USB-devices. The transfer-functions for this device I've already tested. I can access both memory areas separate if I use the appropriate transfer-functions. But I can at the moment only create one device at a time and found no possibility to create a second. Any hints?

 

  • Hi 4711,

    I strongly recommend to use priorities at least 5 or lower (i.e. higher number) for user's threads. Moreover, it's suggested that all threads has a different priority. In ThreadX, the thread can bu resumed up to one tick earlier than requested, for example tx_thread_sleep(1) can "almost immediately" return. Please see ThreadX User's Manual for more details. Your application has tx_thread_sleep(nx_ms_to_ticks(1)); in some places, these threads can starve other threads and NetX IP Internal Thread or internal USBX threads may not function as expected.

    USBX Device Stack User Guide has section "Multiple SCSI LUN" - hope this helps.

    Regards,
    adboc
  • In reply to adboc:

    Hi adboc,

    thank you for your hints. I changed the priorities of
    Init-Thread to 5
    DHCP-Thread to 8
    HTTP-Thread to 6
    and USB0-Thread to 7
    and increased all 1ms-sleeps to at least 2ms. But the behavior of the result is the same as before, unfortunately.
    No idea, whats still wrong.
    I've updated the example archive on my first post if someone wants to test it.

    The chapter "Multiple SCSI LUN" I'll study in within the next time and will give feedback about the result.

    Sorry for my bad english, I'm german.

  • In reply to 4711:

    After reading the chapter about "Multiple SCSI LUN" I realized, that I already did what was suggested there.
    Attached is the content of the struct "g_ux_device_class_storage_parameter" the function "_ux_device_stack_class_register" is called with. But there is only the first drive (0) visible on the PC (and the network always stops working ).

    frupic.frubar.net/36820

  • In reply to 4711:

    Hi 4711,

    You may also use USB Composite Device. Please take a look at example project:

    S7G2_SK_USBX_CompDevice_MS_1_4_0.zip

    Regards,
    adboc

  • In reply to adboc:

    Hi adboc,

    Sorry for the late reply. Was in vacation for the last three weeks.
    I tested your suggestion today. Only changed the board type to S7G2-DK and adding the library sources.
    Equal to my earlier own tests using two different Mass Storage Classes the initialization process stucks in the while-loop starting at line 204 in ux_device_stack_initialize.c because at line 276 (device_framework_length -= descriptor_length) the decriptor_length is 0 making the loop "while (device_framework_length != 0)" endless because "device_framework_length" always stay at 23.
    Is there something other to change in the configuration?
  • In reply to 4711:

    Hi 4711,

    Are you using IAR? Please check suggestion in this post: renesasrulz.com/.../36282

    Regards,
    adboc
  • In reply to adboc:

    Hi adboc,

    thanks for the hints.
    I updated meanwhile to SSP 1.4.0 and IAR 8 to be able to use the posted examples.
    After fixing the known issues coming with this update and after using the example linked by you I was able to initiate and use two independent USB-drives.
    But the main problem, that the network dies if the USB-drives are activated still remains even if I made the project new from scratch.
    I updated the attached example in the first post. The activation of the USB-devices is at first commented out in "usb0_thread_entry.c". So the network starts normally and is usable. Calling the IP of the board with a browser will show the directories of both drives. To activate the USB call "http://<the_boards_IP>/usbon" in the browser.
    The drives appears in the PCs explorer but from now on there is no ping-response and no http-request answered by the board.
    Activating the USB-initialisation in the "usb0_thread_entry.c" there will be no network activity from start on.
    Hope anyone knows, where I made the mistake.
  • In reply to 4711:

    Hi 4711,

    If you suspend the application, do you see anything unexpected on the call stack? What NetX IP Thread and NetX HTTP Server Thread are performing?

    You may also try using nx_ip_info_get or checking NetX IP instance for statistics (please see the beginning of NX_IP structure definition) to see if incoming packets are correctly received or if there are any errors.

    Regards,
    adboc
  • In reply to adboc:

    If the SD/eMMC card attached to the Synergy device is mounted on a PC via the USB Mass storage device interface, so the PC has the filesystem open, it won't be accessible by FileX on the Synergy device. The filesystem on the SD/eMMC device can be opened by the PC or FileX, not both at the same time.
  • In reply to adboc:

    Hi adboc,

    there are no unexpected entries on the call stack.
    The second question regarding the threads I don't understand.

    I'll try to dig into the TCPIP stats to find any irregularities.

     

    Hi Jeremy,

    USB doesn't use the FileX-system. It's working with own block oriented functions direct on the media. Off course changes of the file-system by the PC will not recognised by FileX until a reopen. And this doesn't explain why after initialisation of the USB-devices not even a response on a simple ping-request happens.

  • In reply to adboc:

    Hi adboc,

    I tested the system with the statistical infos. Without USB the number of sent, received and dropped packets is increased constantly. No errors were counted.
    From the point of activating USB all counters are freezed. No further changes. The errors remains on "0" too. It seems that no more packets are processed.
  • In reply to 4711:

    Hi 4711,

    I meant that the call stack should show entries for each thread and the most interesting ones are entries for NetX IP Thread and NetX HTTP Server Thread. If you could, please upload screenshot of the call stack.

    Are you able to run network traffic analyzer like Wireshark or similar tool? Are there any communication? If not, please ensure the Ethernet interrupt is working fine, e.g. by putting a breakpoint in ssp/src/framework/sf_el_nx/enet_irq_veneer.c.

    Regards,
    adboc
  • In reply to adboc:

    Hi adboc,

    thanks for the hints.
    The receive interrupt for the network is always processed. But stepping trough the processes I found, that the allocation of an new packet from the packetpool fails after initialization of the USB.
    Before USB-initialization the packet_pool_id is 1346454347 (I guess this is equal to NC_PACKET_POOL_ID [I nowhere found a declaration for this]) and so the allocation process is continued.


    Immediately after initialization of the USB-device the packet_pool_id changes to a randomly value and stay so for all following calls. All other values in the pointer are destroyed too. So there is no packet processed from now on because the allocation for a new packet fails with a pointer error (0x07).

    Can it be a stack problem?

     

  • In reply to 4711:

    Hi 4711,

    What is the size of the USBX Pool Memory? I have found that if this is too small, the usbx code does not do bounds checking and will write over other memory and cause corruption. I have found that a 64K buffer for MSC class is more than adequate.

    -Gary
  • In reply to garyj:

    Hi Gary,

    thanks for the hint.

    The USBX Pool Memory already was by 32kB. I increased it to 64kB with the same issue. Also increasing the stack size of the USB Stack from 8192 to 16384 didn't solve the behaviour. Always immediately after initialization of the USBX Device Control Driver with ux_dcd_initialize() the Pool Pointer Structure of the Network Thread was destroyed and the packet allocation failed.