Problem with nx_tcp_socket_send while porting code from S7G2 SK to S7G2 DK

I'm working on a webserver application that is currently working on the S7G2 SK. Today I tried to port it to S7G2 DK but I'm seeing some problems. The program starts up,

status = nx_ip_interface_status_check(&g_ip0, 0, NX_IP_LINK_ENABLED, &actual_status, TX_WAIT_FOREVER);

succeeds and it also successfully acquires an IP using the DHCP client.

However, when I try to initiate a connection to the webserver with a web browser, the function

status = nx_tcp_socket_send(&(server_ptr -> nx_http_server_socket), resp_packet_ptr, NX_HTTP_SERVER_TIMEOUT_SEND);

fails with NX_WINDOW_OVERFLOW. I ported it back to the SK and it works fine again. Changes I made mainly concern the Channel 1 Phy Reset Pin (IOPORT_PORT_07_PIN_06 on DK and IOPORT_PORT_08_PIN_06 on SK) in the ethernet driver sf_el_nx. The ethernet channel is set to 1 in both cases. Any idea what could be causing this? For reference, I'm pasting the (shortened) code for responding to the request below.

I have to admit I'm not sure about the calculation of the content length header field in serve_integrated_resources(), so if anyone has comments on that it would be nice as well. It's currently working but I think it should be the length of the data?

 

UINT request_notify(NX_HTTP_SERVER *server_ptr, UINT request_type, CHAR *resource, NX_PACKET *packet_ptr)
{
    SSP_PARAMETER_NOT_USED(server_ptr);
    SSP_PARAMETER_NOT_USED(request_type);
    SSP_PARAMETER_NOT_USED(resource);
    SSP_PARAMETER_NOT_USED(packet_ptr);

    if (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk)
        printf("Requested %s from server while in state %d\r\n", resource, config_state.message_type);
    //Serve resources compiled into the program
    for(unsigned int i = 0; i < sizeof(html_resources) / sizeof(html_resources[0]); i++)
    {
        struct html_resource * res = &html_resources[i];
        //Test of integrated web page serving
        if ((NX_HTTP_SERVER_GET_REQUEST == request_type) && (NULL != strstr(resource+1, res->name)))
            return serve_integrated_resources(server_ptr, request_type, resource, packet_ptr, res);
    }
    return(NX_SUCCESS);
}

UINT serve_integrated_resources(NX_HTTP_SERVER *server_ptr, UINT request_type, CHAR *resource, NX_PACKET *packet_ptr, struct html_resource * res)
{
    UINT        status;
    NX_PACKET   *resp_packet_ptr;
    ULONG       string_length;
    CHAR        temp_string[30];
    ULONG       length = 0;

    length = res->length;

    /* Derive the client request type from the client request.  */
    string_length =  (ULONG) nx_http_server_type_get(server_ptr, server_ptr->nx_http_server_request_resource, temp_string);

    /* Null terminate the string. */
    temp_string[string_length] = 0;

    /* Now build a response header with server status is OK and no additional header info.  */
    status = nx_http_server_callback_generate_response_header(server_ptr, &resp_packet_ptr, NX_HTTP_STATUS_OK, length, temp_string, NX_NULL);

    /* If status is NX_SUCCESS, the header was successfully appended. */

    /* add data to packet */
    status = nx_packet_data_append(resp_packet_ptr, res->data, res->length, server_ptr->nx_http_server_packet_pool_ptr,
                                                  NX_WAIT_FOREVER);
    if (status != NX_SUCCESS)
    {
       nx_packet_release(resp_packet_ptr);
       return status;
    }

    /* Now send the packet! */
    status = nx_tcp_socket_send(&(server_ptr -> nx_http_server_socket), resp_packet_ptr, NX_HTTP_SERVER_TIMEOUT_SEND);

    if (status != NX_SUCCESS)
    {
      nx_packet_release(resp_packet_ptr);
      return status;
    }

    /* Let HTTP server know the response has been sent. */
    return NX_HTTP_CALLBACK_COMPLETED;
}

  • I have done some further testing and realized that the code I posted works with other resources. I think it might be a size issue (buffer, stack, packet,...) that doesn't surface on the SK for some reason. The problem occurs irrespective of the setting for IP fragmentation. Packet Size in Bytes is set to 1500, Number of Packets in Pool to 50.
  • In reply to ChrisS:

    More tests:
    - Tried various sizes of Packet Size and Number of Packets in Pool, no success (in some cases I get a 0x1 error code in nx_tcp_socket_send which isn't listed in the documentation for that function as return value)
    - Tried sending a short test string in the above function instead of web page contained in res->data, works fine

    This leads me to conclude that it's somehow related to the size of the content which is transmitted. Are there any differences in netx/ethernet drivers/configuration or RAM that may have an effect?
  • In reply to ChrisS:

    Hello ChrisS,
    could you try setting the value of Packet Size in Bytes to 1568? This specific value might be required for the connection to work properly.
    BR,
    anper

  • In reply to anper:

    Hello anper,

    just tried that, I still get 0x39 mostly. It was successful one time now but when reloading the page I got 0x39 again. The performance was also quite bad the time it succeeded. The HTML document I want to transfer has a content length of 10848 bytes. I also noticed that with number of packets = 16 it would hang at nx_packet_data_append(resp_packet_ptr, res->data, res->length, server_ptr->nx_http_server_packet_pool_ptr,
                                                      NX_WAIT_FOREVER);

    , presumably because it couldn't fit all data?

    I'm attaching a wireshark capture of the process when it returns 0x39. 192.168.0.20 is a Linux system from which the HTTP request is made and which runs a DHCP server, 192.168.0.12 is the IP assigned to the S7G2 DK. It looks like there are some retransmissions happening but I don't feel competent enough to figure out what's wrong here. If needed I can also provide a capture of a successfull HTTP response when serving another (smaller?) response or more source code.

    tcp_window_overflow.zip

    Some more information:

    I manually create the HTTP server in code with
        status = nx_http_server_create (&g_http_server0, "g_http_server0 HTTP Server", &g_ip0, NULL,
                                                    &g_http_server0_stack_memory[0], 4096, &g_packet_pool0,
                                                    authentication_check, request_notify);

    and global variables

    NX_HTTP_SERVER g_http_server0;
    uint8_t g_http_server0_stack_memory[4096];

  • In reply to ChrisS:

    I have tried to #define NX_HTTP_MULTIPART_ENABLE before including nx_http_server.h but then nx_http_server_create() returns
    NX_PTR_ERROR (0x07) Invalid HTTP Server, IP, media, stack, or packet pool pointer.

    #define NX_HTTP_FRAGMENT_OPTION NX_FRAGMENT_OKAY
    doesn't appear to have any effect on the problem.
  • In reply to ChrisS:

    Hello ChrisS,
    while using Synergy Configurator the nx_http_server_create() function call is already placed in the file related to your HTTP Server thread, for example http_thread.c. Variables g_http_server0 and g_http_server0_stack_memory are also defined there. Probably it is not the reason of your problem, however, is there any particular reason you use it in your application this way and not rely on the generated code?
    BR,
    anper

  • In reply to anper:

    Yes, I do this because I use it without a file system and I didn't see how the configurator let me do this. Please see my previous thread at renesasrulz.com/.../netx-http-server-without-filex or this thread: renesasrulz.com/.../filex-and-netx-http-server
  • In reply to ChrisS:

    Next update:
    I moved the HTTP header into the res-data array and called nx_http_server_callback_data_send(server_ptr, res->data, res->length); instead of the code above. I still get 0x39.

    I also removed the fx_api.h dependency, defined NX_HTTP_NO_FILEX globally and added filex_stub.h/.c but this had no effect on the problem described here.
  • In reply to ChrisS:

    Chris,

    The fact that you code works on the SK but not on the DK leads me to believe that there might be something wrong in your configuration. Please verify that the driver strength for the RMII ethernet interface pins are set to medium or high. The ethernet connection will be extremely flaky with low drive strength.

    -Gary
  • In reply to garyj:

    The DK has dip switches to keep peripherals from fighting each other. Are you sure the dip switches are correct?
  • In reply to Dale Drinkard:

    Gary,
    all EtherC1.RMII pins have drive capacity set to high except for 403 (MDC) and 404 (MDIO) which are set to medium. Pin Group Selection is "_A only" and Operation Mode is blank.
    I also tried creating a new project directly for DK to make sure the errors were not caused by changing the target in the configuration and had the same problems when I inserted my code.

    Dale,
    the switches on S5 are all set to off except for JTAG and ENET1. S101 and S102 are off completely. Ethernet cable is connected to the port on the main board.
  • In reply to ChrisS:

    Hello Chris,

    Can you check if the problem persists when motherboard is detached from the breakout board?

    Regards
  • In reply to Renesas Karol:

    Hello Karol,

    this indeed fixes the problem. Anything I can do to check if there's a defect on the breakout board or a misconfiguration?
  • In reply to ChrisS:

    I'm attaching two pictures of the boards and their jumper settings. The green wire on the breakout board looks a bit strange, I suppose there's a kind of problem that was fixed during production?

  • In reply to ChrisS:

    If memory serves me, the PDC peripheral conflicts with the Ethernet. Make sure the PDC isn't enabled on the breakout board.