Core1 / CYW43 not usable when powered via VSYS pin?

[ChrisVeigl]

Hi,

I came across the issue that when powering the RP Pico (2) W from a LiPo battery via the VSYS pin,
Core1 does not run and the wireless functions cannot be used. It seems that the initialization code of the CYW43 chip (which is partly proprietary) checks for the presence of VBUS using WL_GPIO2 and hangs (!) if VBUS is not present. Even a simple blinky-code in setup1() does not run, although core0 runs normally...

When powering the system via a battery (using VSYS as recommended in the datasheet), VBUS can of course not be present because of the protection diode D1. Does this mean that BT (and effectively, Core1) cannot be used in a battery-powered configuration?

To verify my assumption, I directly connected WL_GPIO2 (at the point of the voltage divider R1/R10) to 3V3(out).
With this HW-patch, Core1 / BT starts normally, also when the system is powered via battery / VSYS.

Is there a function (or SW patch) to disable the check for VBUS in the initialization routine of the CYW chip?
Or another strategy to make BT and core 1 work when powered via the VSYS pin?

thanks!

[earlephilhower]

I'd recommend posting this on the RPI forums directly because it's not really core related if the CYW43 init routine itself if wonky.

That said, I don't understand exactly the symptom you're describing. Or at least, it doesn't seem possible to me. Core1 is started from main before the setup and loop of the sketch are called

arduino-pico/cores/rp2040/main.cpp

Line 180 in 49397a7

multicore_launch_core1(main1);

If the CYW43 init hangs (as part of the variant initialization)

arduino-pico/cores/rp2040/main.cpp

Line 133 in 49397a7

initVariant();

Then the app won't ever progress past line 133 there to start either core0 or core1.

WiFi radio processing is all done on the external chip, and all LWIP/Ethernet polling and injection are done on core0 under IRQ control. So If the CYW43 chip goes out to lunch, core0 will freeze and not core1...

[ChrisVeigl]

thank you very much for your fast response :)
I can confirm that core1 is actually running - I was using the internal LED for showing if core1 runs

digitalWrite(LED_BUILTIN,!digitalRead(LED_BUILTIN));

and that didn't work because digitalWrite/Read commands cause SPI transfers to the CYW43 chip where the LED is connected - and if the CYW is unresponsive, that doesn't work ....

I also verified that

initVariant();

returns when powered via VSYS.
But I'm still wondering how we can use the wireless functions (or the internal LED)
when powering the system via VSYS - which is the recommended way for battery operation ...

[earlephilhower]

That makes more sense, thanks for explaining.

Did you single step through init_cyw43_wifi?

arduino-pico/cores/rp2040/cyw43_wrappers.cpp

Lines 149 to 159 in 49397a7

	extern "C" void init_cyw43_wifi() {
	__isPicoW = CheckPicoW();
	if (__isPicoW) {
	// Fix for overclocked CPU: SPI communication breaks down with default "div by 2" speed
	// So, divide clock by 4 for anything including and above 250MHz CPU frequency.
	if (clock_get_hz(clk_sys) >= 250000000) {
	cyw43_set_pio_clock_divisor(4, 0); // div by 4.0
	}
	cyw43_arch_init_with_country(WIFICC);
	}
	}

It's doing 2 things and it would be good to know which is failing. Does the CheckPicoW return true when on battery power? If not, that's the culprit. We use some code from a Pico appnote to detect the CYW43 chip and maybe it's not valid on battery power. If that call returns true but the cyw43_arch_init_with_country still fails, then it's time to open up a topic on the RPI forum to get feedback from their engineers...

[ChrisVeigl]

I can confirm that CheckPicoW returns true, and that this is not the problem.
Not sure what happens inside cyw43_arch_init_with_country though, think I'd need to build this module with debug info included.

I tested with another RP Pico 2 W (stand-alone, not soldered to our PCB/battery management system

• here there is no issue, the CYW43 seems to start fine, also the built-in LED can be used.

I start to believe that I'm looking at a HW-issue related to either our BMS our the microcontroller used on this PCB.
Sorry for suspecting other reasons - and thanks for your help!

[ChrisVeigl]

I tested with other pico W and pico 2 W boards and there the CYW42 / wireless functions (and the LED) work fine also when powered via VSYS. So this looks like this problem only exists on one PCB - maybe and maybe was caused during the soldering process.

In case this happens to somebody else: connecting WL_GPIO2 (at the voltage divider R1/R2) to 3,3V fixed the problem :)