snip.tcp_client FreeRTOS LwIP

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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?

0 Likes
21 Replies
Anonymous
Not applicable

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.

0 Likes

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 7.45.45.1 (r602358) FWID 01-1920c040

Joining : airportxtrm

Successfully joined : airportxtrm

Obtaining IP address via DHCP

Network ready IP: 10.0.1.7

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

Hello from WICED

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

0 Likes
Anonymous
Not applicable

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.

0 Likes

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.

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

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.

0 Likes

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.

0 Likes
Anonymous
Not applicable

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.

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

discussion.

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

or

wiced_init()

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 ?

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

0 Likes
Anonymous
Not applicable

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.

0 Likes

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

0 Likes
Anonymous
Not applicable

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

0 Likes

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

0 Likes
Anonymous
Not applicable

vik86 I created a video demonstrating how I am using the SDK as well as the assert I am encountering. Hopefully this will clear things up as to the procedure I am following.

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

0 Likes

Matt, two things.

1) You are able put a debug point and you are able to stop at the point where you want to - No issues as we believe you were facing issues here.

2) When you toggle breakpoint and you hit continue, the Assert is invoked

               You expected it to continue, which is not observed - To let you know this is not a typical expected way on using debug in IDE

      To answer why this is happening, wiced_init() invokes a bunch of initialization, one of which is platform init. I believe the debug of IDE is not in sync with platforms state and hence the assert has popped up.

0 Likes

vik86 wrote:

Matt, two things.

1) You are able put a debug point and you are able to stop at the point where you want to - No issues as we believe you were facing issues here.

2) When you toggle breakpoint and you hit continue, the Assert is invoked

               You expected it to continue, which is not observed - To let you know this is not a typical expected way on using debug in IDE

      To answer why this is happening, wiced_init() invokes a bunch of initialization, one of which is platform init. I believe the debug of IDE is not in sync with platforms state and hence the assert has popped up.

Hi mattb@ips-yes.com​,

Can you try change below line:

assert configASSERT( pxQueue );

to below code:

if (!pxQueue) {

        int8_t i = 0; // Just for add some statements below so you can set a break point

         for( ;; ) {

                i++; // Then set break point here

        }

}

This is to prove it really run into pxQueue is NULL case.

(I don't think it's related to IDE issue).

0 Likes
Anonymous
Not applicable

axel.lin did what you suggested. See attached picture.
Screenshot (1).png

vik86 The debug IDE is indeed in sync with the code and the parameter being passed into the xQueueGenericSend function is also indeed NULL. To further prove that the code is in sync I put an #error in the queue.c file to make sure that it is being invoked during compilation. See the below picture:
Screenshot (2).png

Because things can get lost in the thread I'll give a detailed description as to why xQueueGenericSend is being called with a NULL parameter.

1) Application_start() in tcp_client.c is fully executed and starts the tcp_client() timed event.

2) In the first pass through the do-while of tcp_client() the function wiced_tcp_connect() is called and returns a return code of WICED_CONNECTION_RESET. This is important to note because in the snip.tcp_client-BCM94343W_AVN-ThreadX-NetX-debug build this return code is never returned while in the snip.tcp_client-BCM94343W_AVN-FreeRTOS-LwIP-debug it is. I verified this by adding an if statement to catch this particular return code in the do-while loop.

3) In the wiced_tcp_connect() process the function netconn_connect returns a lwip_error of ERR_RST (which is translated to WICED_CONNECTION_RESET via LWIP_TO_WICED_ERR()). This error in turn causes netconn_delete( socket->conn_handler ) to be called which will free the semaphore that will be later used in xQueueGenericSend().

4) Since the tcp_client()'s do while loop conditions of exit were not met yet wiced_tcp_connect() is called again. But this time with the tcp_client_socket->client handler parameter deleted. In the wiced_tcp_connect() process the function do_connect() in api_msg.c is called and fails it's parameter check of "if (msg->conn->pcb.tcp == NULL)". The function even has a comment that states "/* This may happen when calling netconn_connect() a second time */". So the do_connect() function exits the if statement but not before calling sys_sem_signal() with an invalid parameter that was freed from before and not re-allocated.

5) sys_sem_signal() then calles FreeRTOS's xQueueGenericSend() function which asserts at configASSERT( pxQueue ); because the pxQueue parameter was freed and marked null from the previous ERR_RST lwip_error.

There is something wrong in the WICED api code when dealing with FreeRTOS and LwIP. The error code ERR_RST is not being handled properly causing a freeing of resources that are then later inadvertently used.

Another thing to note is that the WICED SDK implements a breakpoint in the assembly of the assert code. This is how the code halts on the assert and why I don't need to "manually" enter a breakpoint to get my debugger to stop. See the below picture of the dissasembly code as to how the compiler implements the assert breakpoint.

Screenshot (3).png

Anonymous
Not applicable

BUMP

0 Likes
Anonymous
Not applicable

BUMP

0 Likes

Hi mattb@ips-yes.com

It has been 2 months since you post this question.

I don't see any fix on the forum. Do you get this issue fixed?

Regards,

Axel

0 Likes