pelwell
commented
3 years ago After some discussion in the office the view is that it is possible that the version number wasn't bumped for the 3B+ change, which is a shame. The rev 1.3 3B+ schematic I have still shows the enable signals as two distinct traces, while the 3A+ clearly shows that WL_ON is also wired to the BT_ON of the modem for layout reasons.
Without a revision change it's going to be difficult to distinguish them. Apart from giving the user a way to override the default for the 1.3 3B+ based on experience, the best bet would probably be to probe for the BT modem with the usual BT_ON (GPIO 0 on the expander) low.
You can use a test script something like this:
#!/usr/bin/perl
my $fd;
system("sudo stty -F /dev/serial1 115200 raw time 2 min 0");
die "* failed to open UART\n" if (!open($fd, '+<', "/dev/serial1"));
$fd->autoflush(1);
print $fd ("\x01\x03\x0c\x00");
my $len = sysread($fd, $buf, 10);
printf("BT: %s (%d)\n", $len ? "on" : "off", $len);
close($fd);This test would be run during installation or before Bluetooth starts up, but for testing purposes disable the HCI startup script (on RPiOS, sudo systemctl disable hciuart).
With the BT_ON line to the modem enabled, the script will provoke it to return a short sequence (usually 7 bytes). When disabled, there is no response and the read returns a length of 0. A manual test might look something like this:
pi@raspberrypi:~$ gpioset gpiochip1 0=0
pi@raspberrypi:~$ ./btprobe
BT: off (0)
pi@raspberrypi:~$ gpioset gpiochip1 0=1
pi@raspberrypi:~$ ./btprobe
BT: on (7)On a 3B+ with BT_ON slaved to WL_ON both btprobes would succeed.
For a production script you would probably replace the printf with a return code indicating whether or not the modem responded.
MichaIng
popcornmix
Describe the bug On some Raspberry Pi 3+ devices, when onboard WiFi is disabled via
dtoverlay=disable-wifi, Bluetooth also stops working. According to some forum threads this seems to be the case when WiFi and Bluetooth share the same reset line:However, there are Raspberry Pi 3+ devices without this issue: https://github.com/MichaIng/DietPi/issues/4512#issuecomment-878613153 This is unexpected since there is only a single revision
a020d3. This makes it difficult to know for installers/scripts whether the WiFi disable overlay needs to be removed as well to enable Bluetooth or not.To reproduce
Expected behaviour Disabling WiFi does not disable Bluetooth as well.
Actual behaviour Disabling WiFi disables Bluetooth as well.
System Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:
Pi3B+cat /etc/rpi-issue)?Raspberrry Pi OS Bustervcgencmd version)?#1421uname -a)?5.10.17-v7+ #1421 SMP Thu May 27 13:59:01 BST 2021 armv7lLogs
Additional context It this is a hardware-wise limitation, not sure if there is a way to have
dtoverlay=disable-wifiignored automatically, as long as Bluetooth is not disabled as well on affected devices? On the other hand I'm not sure whether it's more important to have Bluetooth enabled, when it's expected to be, or to have WiFi disabled, when it's set explicitly via overlay. But probably more important for scripting is whether there is a way to find out in the first place, if the RPi model/system is affected by the issue or not, as the revision code is not sufficient.