Thread kick off too slow

[LanceTaiwan]

Hi,

    I encountered a "Thread kick off too slow" issue.  Let me explain it

My develop environment

Hardware: nRf7002-DK

SDK: 2.6.1

A. I copy the sample  nrf/samples/net/mqtt to my work space, use "wifi_cred add" to connect my WIFI. Everything is running well.

B. Because our environment only allow to use static IP, so I do the following changes

1. Disable DHCP client ( Mark CONFIG_NET_DHCPV4 )
2. Set CONFIG_NET_CONFIG_MY_IPV4_ADDR="192.168.0.201"
3. Set CONFIG_NET_CONFIG_MY_IPV4_GW="192.168.0.1"
4. Set CONFIG_DNS_SERVER_IP_ADDRESSES=y
5. Set CONFIG_DNS_SERVER1="192.168.0.1"

Beside the above changes, I modify nothing.  The result is

1. The samplecan connect to my WIFI and can send MQTT package to the server.
2. The network_task is trigger after 20 seconds ( in network.c )

My question is, if I use DHCP, the network_task is trigger almost immediately, why the same sample delays almost 20 seconds after I change to static IP?  

I tested nrf/samples/wifi/sta , both DHCP/STATIC IP work well.  I already try almost 3 days, any hit?

Thanks

Lance

[Charlie]

Hi Lance,

Thanks for checking with us. I would suggest you to check log to find more clue, choose higher debug level like debug will help you understand which step consume more time.

In case you did not realize, It is also possible to connect Wi-Fi router with static Wi-Fi network configurations like SSID and Password to speed up your network connect. Exercise 2 - Nordic Developer Academy (nordicsemi.com)

Best regards,

Charlie

[LanceTaiwan]

Hi Charlie,

    After I changed log level to 4 ( default is 3 ). A lots of messages come out but they are helpless.  BTY, I follow your comment to set static Wi-Fi network configurations like SSID and Password and the result is the same.

    If I set to static IP, the kernel boot to the first thread will be very slow.  Any other idea?

00:01:08.233,612] <dbg> os: z_impl_k_mutex_lock: 0x2000f680 took mutex 0x2000ff84, count: 1, orig prio: 0
[00:01:08.233,642] <dbg> os: z_impl_k_mutex_unlock: mutex 0x2000ff84 lock_count: 1
[00:01:08.233,642] <dbg> os: z_impl_k_mutex_unlock: new owner of mutex 0x2000ff84: (nil) (prio: -1000)
[00:01:08.233,673] <dbg> os: z_impl_k_mutex_lock: 0x2000f680 took mutex 0x2000ffac, count: 1, orig prio: 0
[00:01:08.233,703] <dbg> os: z_impl_k_mutex_unlock: mutex 0x2000ffac lock_count: 1
[00:01:08.233,734] <dbg> os: z_impl_k_mutex_unlock: new owner of mutex 0x2000ffac: (nil) (prio: -1000)
[00:01:08.233,764] <dbg> os: z_impl_k_mutex_lock: 0x2000f680 took mutex 0x20010024, count: 1, orig prio: 0
[00:01:08.233,795] <dbg> os: z_impl_k_mutex_unlock: mutex 0x20010024 lock_count: 1
[00:01:08.233,795] <dbg> os: z_impl_k_mutex_unlock: new owner of mutex 0x20010024: (nil) (prio: -1000)
[00:01:08.236,053] <dbg> os: z_impl_k_mutex_lock: 0x2000eeb0 took mutex 0x2000d288, count: 1, orig prio: -1
[00:01:08.236,083] <dbg> os: z_impl_k_mutex_unlock: mutex 0x2000d288 lock_count: 1
[00:01:08.236,114] <dbg> os: z_impl_k_mutex_unlock: new owner of mutex 0x2000d288: (nil) (prio: -1000)
[00:01:08.236,480] <dbg> os: z_impl_k_mutex_lock: 0x2000f680 took mutex 0x2000fee4, count: 1, orig prio: 0
[00:01:08.236,541] <dbg> os: z_impl_k_mutex_unlock: mutex 0x2000fee4 lock_count: 1
[00:01:08.236,572] <dbg> os: z_impl_k_mutex_unlock: new owner of mutex 0x2000fee4: (nil) (prio: -1000)
[00:01:08.236,572] <dbg> os: z_impl_k_mutex_lock: 0x2000f680 took mutex 0x2000ff5c, count: 1, orig prio: 0
[00:01:08.236,602] <dbg> os: z_impl_k_mutex_unlock: mutex 0x2000ff5c lock_count: 1

[LanceTaiwan]

Hi Charle,

    Any update?

Lance