1 2 Previous Next 21 Replies Latest reply on Jul 7, 2016 8:59 PM by AxLi_1746341

    snip.tcp_client FreeRTOS LwIP

      I am using the BCM94343W_AVN and attempting to run the snip.tcp_client app with FreeRTOS and LwIP.


      When attaching to the AP I encounter the assert configASSERT( pxQueue ); in the FreeRTOS code in xQueueGenericSend(). The parameter xQueue passed in is NULL.


      When I use ThreadX I do not get this assert. What can cause this error?

        • 1. Re: snip.tcp_client FreeRTOS LwIP

          Some more context:

          xQueueGenericSend() is being called from api_msg.c's function do_connect(). This function is entered twice and on the second time the parameter msg->conn>pcb.tcp is == NULL causing an error. At the end of the do_connect() function is the rtos api function sys_sem_signal(&msg->conn->op_completed); which is called when msg->conn>pcb.tcp is == NULL.


          I tried commenting sys_sem_signal(&msg->conn->op_completed); out but then I get an assert in xQueueGenericReceive() because the xQueue parameter passed in is NULL. I get the feeling that just going through and commenting out the code will just lead to a continuous chain of failure.

          • 2. Re: snip.tcp_client FreeRTOS LwIP

            Hi Matt,


            I tried the snip tcp_client example and did not notice the asserts you are mentioning. Below is the make target I used


            snip.tcp_client-BCM94343W_AVN-FreeRTOS-LwIP download download_apps run


            I did changes in my application to the ip address where the python tcp_echo_server.py is running.

            #define TCP_SERVER_IP_ADDRESS MAKE_IPV4_ADDRESS(10,0,1,9)


            And the output is as show below


            Starting WICED v3.5.2

            Platform BCM94343W_AVN initialised

            Started FreeRTOS v8.2.1

            Initialising LwIP v1.4.0.rc1

            WWD SDIO interface initialised

            WLAN MAC Address : B0:38:29:3A:42:BE



            WLAN Firmware    : wl0: Nov 25 2015 12:57:14 version (r602358) FWID 01-1920c040



            Joining : airportxtrm

            Successfully joined : airportxtrm

            Obtaining IP address via DHCP

            Network ready IP:

            Connecting to the remote TCP server every 2 seconds ...

            Hello from WICED



            Let me know if you have followed these and still see issues

            • 3. Re: snip.tcp_client FreeRTOS LwIP

              I listed the wrong make command. My fault. I used:


              snip.tcp_client-BCM94343W_AVN-FreeRTOS-LwIP-debug  download_apps


              Then ran a debug session where I encounter the assert after attempting to connect to an AP.

              • 4. Re: snip.tcp_client FreeRTOS LwIP

                Whats the reason you are removing "download" in your build string ? Kindly make sure you have download, download_apps is for downloading to external serial flash.

                • 5. Re: snip.tcp_client FreeRTOS LwIP

                  I removed download_apps and replaced it with just download, and the result is the same.


                  snip.tcp_client-BCM94343W_AVN-FreeRTOS-LwIP-debug download

                  • 6. Re: snip.tcp_client FreeRTOS LwIP

                    During my digging into this assert problem I discovered that the semaphore is marked invalid via the void sys_sem_set_invalid( sys_sem_t *sem ) function.


                    One of the differences in operation between the ThreadX build and FreeRTOS build is the return code from wiced_tcp_connect( &tcp_client_socket, &server_ip_address, TCP_SERVER_PORT, TCP_CLIENT_CONNECT_TIMEOUT );


                    The ThreadX build returns WICED_TCPIP_SOCKET_CLOSED (this is because I don't have the python script, that acts as the host, running) from wiced_tcp_connect() and proceeds to attempt to tcp connect again 2 seconds later with out issue.


                    The FreeRTOS build returns WICED_CONNECTION_RESET (again, the python script is not running, and should not need to be) from wiced_tcp_connect(). Before wiced_tcp_connect() is called again, sys_sem_set_invalid() is called in the process invalidating the semaphore used by the tcp thread. So when wiced_tcp_connect() is called again 2 seconds later the assert occurs because the semaphore was marked invalid.


                    So, the key difference between the ThreadX and FreeRTOS build so far seems to be the return code from wiced_tcp_connect() being

                    WICED_TCPIP_SOCKET_CLOSED and WICED_CONNECTION_RESET respectively. Why  WICED_CONNECTION_RESET occurs in the FreeRTOS build and not the ThreadX build is still a mystery.

                    • 7. Re: snip.tcp_client FreeRTOS LwIP

                      Is this an issue in debugging your application ? The two different network stacks operate a bit different, there might be a possibility that both are not handled in similar fashion and hence you see different returns. But let us know if you see any errors and you are not able to proceed.

                      • 8. Re: snip.tcp_client FreeRTOS LwIP

                        I do see errors, the error being that using the FreeRTOS and lwip build doesn't work with the WICED-SDK/apps/snip/tcp_client example. And I have to use FreeRTOS and lwip as per our customer request. The application I'm using as a starting point is Broadcom's example code WICED-SDK/apps/snip/tcp_client and it is currently unmodified. I'm trying to run the demo tcp_client first to make sure I have a solid functioning example before adapting it to my customers needs. But the tcp_client demo does not work as per my customers requirements.


                        I'm currently at a loss as to how to fix it since it has something to do with the Broadcom/FreeRTOS/lwip code. The best I can do is give the analysis as seen above and continue to dig into the Broadcom/FreeRTOS/lwip code and try to solve the error.


                        Do you not get the assert when you attempt to debug and/or simply run the tcpip_client?


                        Are you following the procedure of:

                        1. build and download using snip.tcp_client-BCM94343W_AVN-FreeRTOS-LwIP-debug download
                        2. run a debug session
                        3. have the Avenet BCM94343W connect to an access point
                        4. Monitor the debug session to see if it encounters the configASSERT( pxQueue ); in the xQueueGenericSend function.
                        5. Monitor debug console output and ensure it attempts to connect to the TCP server every 2 seconds, if it stops after stating "Connecting to the remote TCP server every 2 seconds..." once then the assert failure was encountered.
                        • 9. Re: snip.tcp_client FreeRTOS LwIP

                          vik86 wrote:


                          Is this an issue in debugging your application ? The two different network stacks operate a bit different, there might be a possibility that both are not handled in similar fashion and hence you see different returns. But let us know if you see any errors and you are not able to proceed.

                          No, your statement does not make sense.

                          The low level network stacks can have different implementation, but the

                          reason to add WICED_* APIs layer is to provide a common interface for upper

                          application layer.


                          AFAICT, the LWIP_TO_WICED_ERR in lwip build and the

                          netx_returns/netx_duo_returns table in NetX/NetX_Duo build should convert

                          to exactly the same error for different network stacks.


                          BTW, mattb@ips-yes.com provides a very clear and reproduceable steps in the follow up


                          • 10. Re: snip.tcp_client FreeRTOS LwIP

                            Matt yes I was able to see the assert's coming up. This happened  when I put the debug point on


                              result = wiced_network_up_default( &interface, &device_init_ip_settings );



                            and not on other lines.


                            But if you continue your debug execution ignoring the asserts it continues the debug process.

                            Could you let us know if you are able to continue your debug ?


                            AxLi_1746341 kindly read the response. I know the WICED api's is common for the network stack.

                            • 11. Re: snip.tcp_client FreeRTOS LwIP

                              I just tried debugging ignoring the asserts and even more asserts occurred to the point where the whole system finally hard faulted.


                              How are you able to continue to debug ignoring the asserts? Because when I do I encounter the aforementioned hard fault.


                              Also, you should not have to set a breakpoint to "see" the asserts. The asserts automatically stop the code when they fail.


                              The assert will not occur until wiced_tcp_connect() in the tcp_client.c file is called the 2nd time in the do{}while() loop and not before. Are you getting asserts before wiced_tcp_connect() or are you stopping the code using breakpoints before wiced_tcp_connect()? Because that is what it sounds like what you are doing and is not the symptom I'm seeing.

                              • 12. Re: snip.tcp_client FreeRTOS LwIP

                                can you point to the line numbers where you are placing the debug points?

                                • 13. Re: snip.tcp_client FreeRTOS LwIP

                                  I'm not setting any breakpoints, just running the code. The asserts automatically stop the code.


                                  But, the very first assert that I get is line 663 of RTOS/FreeRTOS/ver8.2.1/source/queue.c, configASSERT( pxQueue );

                                  • 14. Re: snip.tcp_client FreeRTOS LwIP

                                    Just to get things clear,the debug flag in the SDK does not mean the debug logs are going to be enable or you would notice more logging traces

                                    You will use debug for  the eclipse IDE debug  capabilities to go over step by step debugging by adding a breakpoint on a particular line you would like to start debugging.

                                    If you have not set the debug point then you are sure to land to unknown asserts. So kindly place a debug tracepoint and then try debugging.

                                    Also to configure debug in eclipse IDE refer here :Creating and/or Editing Debug Configurations

                                    1 2 Previous Next