- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is WiFi Direct test environment.
- WICED SDK 2.4.0
- ThreadX & NetX Duo
- Apps/snip/p2p
- WiFi Direct with Galaxy Note 2
And, here is the test log of my problem.
.....................
WLAN MAC Address : CC:52:AF:C6:CF:50
STA MAC: CE:52:AF:C6:CF:50
P2P discovery enabled. Advertised as 'WICED-P2P'
Found P2P device: SHV-E250S
P2P negotiation complete...
Starting WPS Enrollee
Joining 'DIRECT-cb-SHV-E250S'
Sending Identity
Sending Identity
Sending nonce
Sending hashes
Storing credentials for DIRECT-cb-SHV-E250S
Sending WSC Done
WPS completed successfully
WPS complete
(hang up)
And, I found something starange in WICED-SDK.
besl_wps_deinit() => besl_wps_wait_till_complete() => host_rtos_join_thread()
host_rtos_join_thread()
{
.....................
while ( thread->tx_thread_state != TX_COMPLETED )
{
host_rtos_delay_milliseconds( 10 );
}
......................
}
In above, <tx_thread_state> always returns TX_READY(not TX_COMPLETED).
In other words, because <wiced_wps_thread_main() in Apps/snip/p2p> was called by a function not by a thread, so I think that <Apps/snip/p2p and above source code> is strange. Am I wrong?
Please give me your opinions about that.
Steve
- Labels:
-
Wi-Fi Direct
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
Could not followed your question, can you rephrase it?
Keep in mind that, the start of the p2p (application_start()) is called from the main thread.
Seyhan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's not easy to explain the source code analysis.
I would say the 2 snip codes(wps and p2p) and the difference of them.
1. apps/snip/wps_registar/wps_registar.c
I just simplified the source code, as below.
void application_start( )
{
if ( wiced_wps_registrar( ) == WICED_SUCCESS )
}
wiced_result_t wiced_wps_registrar()
{
besl_wps_init ( );
result = besl_wps_start( workspace, );
if ( result == WICED_SUCCESS )
{
besl_wps_wait_till_complete( workspace );
result = besl_wps_get_result( workspace );
}
}
wiced_result_t besl_wps_start( )
{
result = host_rtos_create_thread_with_arg(, wiced_wps_thread, );
}
static void wiced_wps_thread( uint32_t arg )
{
wiced_wps_thread_main( arg );
}
After more simplifying it,
void application_start( )
{
besl_wps_init ();
result = host_rtos_create_thread_with_arg( , wiced_wps_thread, );
besl_wps_wait_till_complete( workspace );
}
static void wiced_wps_thread( uint32_t arg )
{
wiced_wps_thread_main( arg );
}
In above, in my guessing, besl_wps_wait_till_complete() wait wiced_wps_thread.
In other word, besl_wps_wait_till_complete() wait a return of wiced_wps_thread_main().
2. apps/snip/p2p/p2p.c
I just simplified the source code, as below.
void application_start( )
{
besl_p2p_init ( &workspace, &device_details );
besl_p2p_start( &workspace );
}
besl_result_t besl_p2p_start( p2p_workspace_t* workspace )
{
message.type = P2P_EVENT_START_REQUESTED;
host_rtos_push_to_queue(&p2p_message_queue, &message, WICED_NEVER_TIMEOUT);
}
besl_result_t besl_p2p_init( p2p_workspace_t* workspace, )
{
host_rtos_create_thread_with_arg( , p2p_thread_main, );
}
static void p2p_thread_main( uint32_t arg )
{
p2p_run_as_client( workspace, wps_agent );
}
static besl_result_t p2p_run_as_client( p2p_workspace_t* workspace, wps_agent_t* wps_enrollee )
{
wiced_wps_thread_main((uint32_t)wps_enrollee);
besl_wps_deinit( wps_enrollee );
}
wiced_result_t besl_wps_deinit( wps_agent_t* workspace )
{
besl_wps_wait_till_complete( workspace );
}
After more simplifying it,
void application_start( )
{
host_rtos_create_thread_with_arg( , p2p_thread_main, );
message.type = P2P_EVENT_START_REQUESTED;
host_rtos_push_to_queue(&p2p_message_queue, &message, WICED_NEVER_TIMEOUT);
}
static void p2p_thread_main( uint32_t arg )
{
wiced_wps_thread_main((uint32_t)wps_enrollee);
besl_wps_wait_till_complete( workspace );
}
In above, what does besl_wps_wait_till_complete() wait?
main thread? ==> I don't think so.
p2p_thread_main? ==> as above, it's impossible.
wiced_wps_thread_main? ==> unlike <apps/snip/wps>, it's not a thread
In my test, <below while loop> never return in <p2p example>.
wiced_result_t besl_wps_wait_till_complete( wps_agent_t* workspace )
{
host_rtos_join_thread( &host_workspace->wps_thread );
}
wiced_result_t host_rtos_join_thread( host_thread_type_t* thread )
{
while ( thread->tx_thread_state != TX_COMPLETED )
{
host_rtos_delay_milliseconds( 10 );
}
}
Is there anybody who can tell if <apps/snip/p2p> works well or not?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. Hangup in besl_wps_wait_till_complete()
Regarding above issue, after not calling besl_wps_wait_till_complete(), <apps/snip/p2p> worked well.
But, I'm not sure this is right.
I'm still waiting your advice......
2. <apps/snip/p2p> between 2 WICED modules (run as group owner)
As above, I tested <apps/snip/p2p> with <a WICED module & some smartphones>, and it worked well.
In these test, I checked that the WICED module always run as p2p-client (not as p2p-group-owner).
Now, I tried <apps/snip/p2p> with 2 WICED modules, but it never succeeded.
Anyway, here are my questions.
A. Does <apps/snip/p2p> work well between 2 WICED modules?
B. How can the WICED module run as p2p-group-owner?
Thanks in advance.....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe SDK 2.4.1 has fixed this issue.
Can you try the snippet application in SDK 2.4.1 to verify?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm using SDK 2.4.1 with WICED device and using an Android phone to connect to WICED. I see the following:
Platform BCM943362WCD4 initialised
Started ThreadX v5.5
Initialising NetX_Duo v5.6
Creating Packet pools
WWD SDIO interface initialised
WLAN MAC Address : 40:2C:F4:AF:31:D5
WLAN Firmware : wl0: Feb 10 2014 11:29:55 version 5.90.230.7 FWID 01-555f783e
STA MAC: 42:2C:F4:AF:31:D5
Found P2P device: ABC123
Essentially after the discovery of the peer device, WICED seems to be stuck. The Android phone has no issues connecting to other devices. Anyone else seeing this.
Thanks,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ssekim,
I have not tried this but you could make a peer get negotiated to a GO by giving it a higher intent value (see besl_p2p_device_detail_t.group_owner_intent ). The range is 0-15.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Discussion is being locked. If you have any follow-up, please start a new discussion.