No +WFJAP event if initial connect fails

Hello,

We're noticing that if for some reason WFJAP initial connect fails (such as failed to get an IP address) and DA16200 retries the connect, there is no +WFJAP event that gets generated when it finally succeeds.We are running with WFDIS=0 and DPM=1 and on SDK 3.2.4.0 with basic AT command "getting started" example.

Here are logs on our MCU, you can see WFJAP command and corresponding OK.

rtt:~$ [00:04:53.377,929] <dbg> modem_cmd_handler: modem_cmd_send_ext: SENT DATA
41 54 2b 57 46 44 49 53 3d 30 |AT+WFDIS =0
rtt:~$ [00:04:53.703,887] <dbg> modem_cmd_handler: cmd_handler_process_rx_buf: RECV
4f 4b |OK
rtt:~$ [00:04:53.703,948] <dbg> modem_cmd_handler: cmd_handler_process_rx_buf: match cmd [OK] (len:2)
rtt:~$ [00:04:53.704,193] <dbg> modem_da16k: mdm_connect_work: Connecting with command AT+WFJAPA='KKSD2','password',1
rtt:~$ [00:04:53.704,223] <dbg> modem_cmd_handler: modem_cmd_send_ext: SENT DATA
41 54 2b 57 46 4a 41 50 41 3d 27 4b 4b 53 44 32 |AT+WFJAP A='KKSD2
27 2c 27 6b 6f 6e 77 69 72 65 6c 65 73 73 27 2c |','password',
31 |1
rtt:~$ rtt:~$ [00:04:55.003,753] <dbg> modem_cmd_handler: cmd_handler_process_rx_buf: RECV
4f 4b |OK
    // and after that there is nothing else from DA16200
On the DA16200 UART

21:43:16 --> ### User Call-back : Success to connect Wi-Fi ...
21:43:17 --> -- DHCP Client WLAN0: BOUND(10)
21:43:17 --> . Assigned addr : 192.168.2.48
21:43:17 --> . Lease Time : 24h 00m 00s
21:43:17 --> . Renewal Time : 20h 00m 00s
21:43:17 -->
21:44:13 --> OK
21:44:13 -->
// Disconnected with WFDAP
21:44:13 --> >>> Network Interface (wlan0) : DOWN
21:44:13 --> .[1;31m[wpa_supplicant_event_disassoc] CTRL-EVENT-DISCONNECTED bssid=f0:79:59:75:ee:00 reason=3 locally_generated=1
21:44:13 --> .[0mOK
21:44:13 -->
21:44:13 --> ### User Call-back : Wi-Fi disconnected ( reason_code = 3 )
21:44:13 --> ...
21:44:14 --> 0
21:44:14 -->
21:44:15 -->
// Connect with WFJAPA
21:44:15 --> >>> Network Interface (wlan0) : UP
21:44:15 --> >>> Associated with f0:79:59:75:ee:00
21:44:15 --> .[1;32m
21:44:15 --> Connection COMPLETE to f0:79:59:75:ee:00.[0m
21:44:15 --> L2 Pack
21:44:15 --> et process completed, Set DPM Sleep !!!
21:44:15 --> [do_dpm_autoarp_send] gw ipaddr(0) is wrong
21:44:15 -->
21:44:15 --> -- DHCP Client WLAN0: REQ(1)
21:44:15 -->
21:44:15 --> ### User Call-back : Success to connec
21:44:15 --> t Wi-Fi ...
// IP not assigned error
21:44:22 --> .[1;33mIP not assigned
21:44:22 --> .[0m
21:44:22 --> >>> Network Interface (wlan0) : DOWN
21:44:22 --> .[1;31m[wpa_supplicant_event_disassoc] CTRL-EVENT-DISCONNECTED bssid=f0:79:59:75:ee:00 reason=1 locally_generated=1
21:44:22 --> .[0m
21:44:22 -->
21:44:22 --> ### User Call-back : Wi-Fi disconnected ( reason_code = 1 ) ...
21:44:22 -->
21:44:22 --> >>> Network Interface (wlan0) : UP
21:44:22 --> >>> Associated with f0:7
21:44:22 --> 9:59:75:ee:00
21:44:22 --> .[1;32m
21:44:22 --> Connection COMPLETE to f0:79:59:75:ee:00.[0m
21:44:22 --> L2 Packet process completed, Set DPM Sleep !!!
21:44:22 --> [do_dpm_autoarp_send] gw ipaddr(0) is wrong
21:44:22 --> -- DHCP Client WLAN0: SEL(6)
21:44:23 -->
21:44:23 --> ### User Call-back : Success to connect Wi-Fi ...
21:44:26 -->
// Successful connection but no +WFJAP notification
21:44:26 --> -- DHCP Client WLAN0: REQ(1)
21:44:27 --> -- DHCP Client WLAN0: BOUND(10)
21:44:27 --> . Assigned addr : 192.168.2.48
21:44:27 --> . Lease Time : 24h 00m 00s
21:44:27 --> . Renewal Time : 20h 00m 00s
21:44:27 -->
If the connection succeeds on the first try, we do correctly get +WFJAP. This is what it looks like. So we do know that our MCU is able to correctly receive and parse +WFJAP.
rtt:~$ [00:11:17.263,549] <dbg> modem_cmd_handler: cmd_handler_process_rx_buf: RECV
2b 57 46 4a 41 50 3a 31 2c 27 4b 4b 53 44 32 27 |+WFJAP:1 ,'KKSD2'
2c 31 39 32 2e 31 36 38 2e 32 2e 34 39 |,192.168 .2.49
In summary, two questions:
1. Why does DA16200 not respond with +WFJAP if the connection doesn't succeed on the first try?
2. It also appears that while this connection is ongoing, DA16200 doesn't respond to any AT commands. Is that expected? 
Thanks,
Konstantin
  • Hi Konstantin,

    Thank you for posting your question online.
    Let me check on this and I will get back to you.

    Kind Regards,
    OV_Renesas

  • Hi Konstantin,

    Apologies for the delay.
    Question 1: Why does DA16200 not respond with +WFJAP if the connection does not succeed on the first try?
    Our Team was able to reproduce this issue when the DA16200 DPM is enabled. It could be good to send the AT+WFJAP command after AT+DPM=0, then you can have the response when it failed as shown below(30 seconds later):

     AT+WFJAP=RENESAS_CS,3,1,TESTEST12
     OK
     
     +WFJAP:0,OTHER,0 

    When you have set the AT+DPM=1 first, the device goes into abnormal sleep mode before DA16200 responds to the AT+WFJAP command in failed case.
    Question 2: It also appears that while this connection is ongoing, DA16200 does not respond to any AT commands. Is that expected?
    Yes, it is expected. What commands do you want to run at the same time? From my understanding the AT command task is not ready to have any other command until the WFJAP command is done.
    After testing, it responded after 30seconds:
    [Mon Mar 06 18:56:34.661 2023] AT+WFJAP=RENESAS_CS,3,1,TESTEST12
    [Mon Mar 06 18:56:35.766 2023] OK
    [Mon Mar 06 18:57:04.940 2023] 
    [Mon Mar 06 18:57:04.940 2023] +WFJAP:0,OTHER,0
    [Mon Mar 06 18:57:04.940 2023] AT
    [Mon Mar 06 18:57:04.940 2023] OK
    [Mon Mar 06 18:57:04.940 2023] AT
    [Mon Mar 06 18:57:04.940 2023] OK
    [Mon Mar 06 18:57:04.940 2023] AT
    [Mon Mar 06 18:57:04.940 2023] OK


    Kind Regards,
    OV_Renesas

  • I don't think it actually goes into sleep because we can query the connected status after about 15 seconds and da16k responds. So it's not actually sleeping. This feels like a bug in the SDK.

    We don't want to keep turning DPM on and off since it reboots the da16200.

  • Hi Konstantin,

    Please find the attached file which you will have to apply into your project. Our Team modified it a bit to get the response and then get into abnormal sleep mode. 

    da16200_wfjap_response_fix.zip

    Kind Regards,
    OV_Renesas