RTL8720DN SDK crash/resets when connecting to close AP

Definitely open AP. I control it and open to all devices i have tested. If the "start auth " message is not supposed to be emitted, this may indicate a firmware problem with lib_wlan.a.
I am plotting current usage of the device and noticed the failed attempts draw a peak of 400ma+ whereas if I put my finger on the antenna and it succeeds, the peak draw is 200ma.
I shall post oscilloscope plots of current draw but this indicates the firmware is doing something extraordinary while connecting to an open/noencryption AP with high signal levels. My guess is that, as you suggested, there is some poor interaction between hardware and software that may be causing this extraordinary behavior.

This is very odd and indeed abnormal, even BW16 is also using the ARM Cortex-M arch, power consumption should be very low even when connecting to the AP, around 80mA and standby at 20mA

@lamb

WiFi_Scenario5.zip.xml (413.1 KB)
This file has recently compiled images using the GitHub SDK, running the WiFi scenario 5 example. It attempts to connect to a open WiFi network with “Test_ap” as the SSID.
Can you download the file, remove the .xml extension, unzip, and upload the images using ImageTool and test it out?
I have tested on my BW16 connecting to my phone hotspot resting on the table next to it, with RSSI around -16, and have had no issues.

Similarly, you previously stated that you could recreate the issue with the GitHub SDK. Can you download the latest files from GitHub, compile and verify that the issue still exists, and upload the image files in the same way for me to test?

I think testing the same images can help isolate the source of the error.

Renamed my SSID to Test_ap and uploaded with imagetool. Same behavior as before. Crashing/rebooting (see below). I have 0.1+10uF SMD caps between Vcc pad and shield (ground) as the AI-Thinker data sheet says but I still believe this is a power supply/grounding problem due to current spikes (<10ms) and the fact that all is fine for attenuated signals. Going to try soldering a 3.3V regulator directly on the BW16 module driven by a high current 5V supply to see if that works.
Test output:

— RESET —
#calibration_ok:[2:19:11]
#interface 0 is initialized
interface 1 is initialized
Initializing WIFI …[FAST_CONNECT] Fast connect profile is empty, abort fast connection
WIFI initialized
init_thread(58), Available heap 0x25780
[WLAN_SCENARIO_EXAMPLE] Wi-Fi example scenario case 5…
[WLAN_SCENARIO_EXAMPLE] Enable Wi-Fi
WIFI is already running
[WLAN_SCENARIO_EXAMPLE] Connect to AP using STA mode
RTL8721D[Driver]: set ssid [Test_ap]
— REBOOTS HERE and REPEATS FROM ABOVE —
(Oh yeah. If I put my finger over the antenna, it works)

Plots of current usage across 1ohm resistor to ground. BW16 still bypassed between vcc and shield with 0.1+10uF as per AI-Thinker. I have tried 47uf but still a problem. So I am going to try soldering a dedicated regulator directly on the BW16 module in an attempt to further reduce impedances/voltage drops/ripple.
100mv = 100ma. Notice >350ma just before reboot. The low current after reset is a delay I added in the code to aid in matching to osciliscope trace.

Putting a 1 amp 3.3 V regulator directly on the BW16 module* and driving with a high current +5 V source (not off a multi port USB adapter off my PC like I had been doing) seems to solve the high rssi open 2.4ghz AP problem most of the time. This combination seems to be able to handle the high current spikes. Still would be nice to understand why attenuating the signal makes all these problems go away without any of this. I still feel a peek at the lib_wlan.a source files would provide some insight.
I am using AP2114 low dropout 1A regulator though the NCP167 low noise 0.7A regulator is what I may use in the PCBs.
image
*AI-Thinker BW16 datasheet does say 450MA @ 3.3V so I was warned.

Arghh…! Dedicated regulator and clean high current source does NOT fix the problem on all the BW16 modules I am testing. Sadness and despair. Crash reboot on open AP even when not right next to the AP. Guess ill wait for the next batch of BW16 but this does not bode well for production. Is there a process to get source code to lib_wlan.a ? NDAs etc?
Is there a way to go from MAC address to batch number? Mac address of one of my bad acting modules is 94:c9:60:1b:fa:ed

1 Like

Hi @lamb

I do share your frustration here, but reading your post I realised that you are actually working on the BW16 module directly and that could be the problem here, bcos we are all using a dev board for testing, power managment is already handle by onboard circuit. From the information you provide, there is a sudden power surge(~400mA) when WLAN is trying to connect to nearby strong AP signal, this is unsual but I have tested it on the BW16 dev boards and all seems working fine.

If you really wanna take a look at the WLAN library, you may have to sign an NDA to access more source code and technical documents, please read the information below,

@lamb

WiFi MAC address of modules are configured when manufactured at written into eFuse. Refer to Chapter 18.2.10 of AN0400 Application Note on the API to use to change the MAC address.

To wyy:

Fresh Ubuntu, fresh SDK, fresh build of OPEN AP test - detailed steps below. Same problem and behavior as before. Zip file of bin files here. Hardware as in diagram (BW16 V1.2 + AP2114 soldered directly to module)

foo3.xml (397.5 KB)

------ output -------
#calibration_ok:[2:19:11]
#interface 0 is initialized
interface 1 is initialized
Initializing WIFI …
WIFI initialized
init_thread(58), Available heap 0x25800
[WLAN_SCENARIO_EXAMPLE] Wi-Fi example scenario case 4…
[WLAN_SCENARIO_EXAMPLE] Enable Wi-Fi
WIFI is already runningPlease set CONFIG_ENABLE_WPS 1 in platform_opts.h to enable WPS
[WLAN_SCENARIO_EXAMPLE] Disconnect from AP
WIFI wlan0 Setting:
“==============================”
MODE => STATION
SSID =>
CHANNEL => 1
SECURITY => OPEN
PASSWORD =>
Please set CONFIG_ENABLE_P2P 1 in platform_opts.h to enable P2P
WIFI is already running
[WLAN_SCENARIO_EXAMPLE] Connect to AP use STA mode
RTL8721D[Driver]: set ssid [Test_ap]
— REBOOTS HERE —
REPEATS FROM TOP

------- steps ---------
Just did this today 20220220

git clone GitHub - ambiot/ambd_sdk: Release SDK for AmebaD
emacs ambd_sdk/project/realtek_amebaD_va0_example/inc/inc_hp/platform_opts.h
CONFIG_EXAMPLE_WLAN_SCENARIO 1
CONFIG_EXAMPLE_WLAN_FAST_CONNECT 0
CONFIG_ENABLE_WPS 0
emacs ambd_sdk/component/common/example/example_entry.c
example_wlan_scenario(“S4”);
apt-get install libc6-i386
cd ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/project_lp
chmod +x asdk/gnu_utility/prepend_header.shPreformatted text
chmod +x asdk/gnu_utility/image_tool/imagetool.sh
chmod +x asdk/gnu_utility/pad.sh
make all
cd …/project_hp
chmod +x asdk/gnu_utility/prepend_header.sh
chmod +x asdk/gnu_utility/image_tool/imagetool.sh
chmod +x asdk/gnu_utility/pad.sh
make all
cd asdk/image
cp -p …/…/…/project_lp/asdk/image/km0_boot_all.bin .
zip foo3.xml km0_km4_image2.bin km0_boot_all.bin km4_boot_all.bin
Used ambd_sdk/tools/AmebaD/Image_Tool/ImageTool.exe to “Download”
ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/project_hp/asdk/image/km0_boot_all.bin to 0x08000000

ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/project_hp/asdk/image/km4_boot_all.bin to 0x08004000

ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/project_hp/asdk/image/km0_km4_image2.bin to 0x08006000

Hi @lamb

If you signed NDA and receive the NDA technical document, then you will be able to see the Application Note at Chapter 15.1.2 for the detailed Power Consumption Summary, you can see from the table that for Ameba D chip, the power consumption when transmitting at 2.4GHz with stronger signal(like in your case) typically range from 200mA to 300mA so I think you need to provide the module with enough power before proceed with next batch, the whole thing could be just a under-power issue,

Thank you for this. I will look into that section. As you see from what I am trying now - yet still seems to fail - I have a 1 Amp 3.3V regulator driving the BW16 module. This initially seemed to fix problems for a few of our prototypes but then I found one where the problem still occurs. I shall continue to experiment and focus on the power supply requirements. Thank you again for the help.

BTW: putting my finger on the antenna still ALWAYS works :slight_smile:

While I wait for the NDA process to complete, I measured ripple at < 20mv at 3.3V at the VCC pad of the BW16 running the binaries I uploaded in response to wyy. Still exhibits the exact same behavior so it may not be a power problem. Instead it may be a RF layout issue inside or outside the module. This would somewhat fit the fact that putting my finger over the antenna always solves the problem. Does anyone from B+T who manufactures the BW16 module see these posts?

@lamb

foo3.xml contained images running scenario 4 of the WiFi example, which uses WPS that is not applicable here. Nonetheless, it seemed like my BW16 could connect to WiFi network.

#calibration_ok:[2:19:11]
#interface 0 is initialized
interface 1 is initialized

Initializing WIFI ...
WIFI initialized

init_thread(58), Available heap 0x25800

[WLAN_SCENARIO_EXAMPLE] Wi-Fi example scenario case 4...

[WLAN_SCENARIO_EXAMPLE] Enable Wi-Fi

WIFI is already runningPlease set CONFIG_ENABLE_WPS 1 in platform_opts.h to enable WPS

[WLAN_SCENARIO_EXAMPLE] Disconnect from AP


WIFI  wlan0 Setting:
==============================
      MODE => STATION
      SSID =>
   CHANNEL => 1
  SECURITY => OPEN
  PASSWORD =>
Please set CONFIG_ENABLE_P2P 1 in platform_opts.h to enable P2P

WIFI is already running
[WLAN_SCENARIO_EXAMPLE] Connect to AP use STA mode

RTL8721D[Driver]: set ssid [Test_ap]

RTL8721D[Driver]: start auth to 5e:59:dc:04:2d:f8

RTL8721D[Driver]: auth alg = 0

RTL8721D[Driver]:
OnAuthClient:algthm = 0, seq = 2, status = 0, sae_msg_len = 12

RTL8721D[Driver]: auth success, start assoc

RTL8721D[Driver]: association success(res=1)
wlan1: 1 DL RSVD page success! DLBcnCount:01, poll:00000001

Interface 0 IP address : 192.168.95.179

Unfortunately, AiThinker/B&T staff do not follow posts on this forum.
If you are seeing this issue on multiple BW16 modules, it may be a hardware issue with a batch of modules. Perhaps it would help if you could contact the seller/manufacturer regarding this.

I set CONFIG_ENABLE_WPS to zero so that it was only OPEN 2.4Ghz AP (like a hotel hotspot) for my issue to occur. My recent post even has a 0.1uf AND 1.5 F (farad) low esr supercapacitor tied to the vcc pad of the BW16 to force <20mv of ripple on the power line and I still get the problem.
I must just have hit a few batches of bad BW16. A few from digikey and a few from seeed. Too bad as this makes the BW16’s not ready for production. Will get the source code to lib_wlan.a hopefully so that I can track down the exact point at which the problem occurs and try to find a s/w workaround.
Do you know a source of BW16 that is better?

Some minor progress. I think I have a hardware workaround for the moment. Just thought I would share (will also contact AI-Thinker). I still look forward to NDA process to understand the basis for “frantic” wifi connect behavior seen in oscilloscope traces here: