GitLab

We appear to be getting corrupted data or nonzero static global structs when
running the firmware after leaving BLE firmware update mode.

Depending on the build, this could make the hub not boot after installation.

Fixes https://github.com/pybricks/support/issues/1408

DriveBase is finally no longer alone.

These aren't used for anything, and deleting them saves precious bytes on Move Hub.

This makes no difference for the Light class, but it makes the class usable for certain custom devices.

If a host tries to write more than MTU - 3 bytes to an attribute, the
host should do a prepared write to split up the write into multiple long
writes. We currently don't support this. So we need to send an error
response to the prepared write request. The host may also follow this
with an execute write command to cancel the prepared write, so we need
to respond to that too.

Issue: https://github.com/pybricks/support/issues/947

This finishes a TODO in the CC2640 driver to send the correct max
payload size to the host via the Pybricks hub capabilities
characteristic. Previously, this was hardcoded to use the hub max MTU
size. But some Bluetooth adapters have a smaller MTU size, so we need
to use the smaller of the two.

Fixes: https://github.com/pybricks/support/issues/947

This adds a task parameter to pbdrv_bluetooth_stop_broadcasting(). This
allows us to finish the TODO of waiting for the broadcasting to stop
before exiting the MicroPython runtime.

This adds a task parameter to pbdrv_bluetooth_stop_observing(). This
allows us to partially fix a TODO of waiting for the observation to
stop before exiting the MicroPython runtime. Also in the case of the
CC2640, pbdrv_bluetooth_stop_observing() can be called from multiple
places, so to be safe, we need to make sure each caller has its own
task struct to avoid reentrancy issues.

The Bluetooth chip on the City and Technic hubs will stop receiving
advertisements after a while when observing. It isn't clear why this
is happening, but it seems to that there is a bug in the Bluetooth
chip firmware that causes it to start filtering out advertisements
from an individual advertiser after a while (i.e. it can still be
receiving advertisements from one device but stops receiving them
from another). Eventually it will stop receiving advertisements from
all devices.

To work around this, we restart the observation process every 10
seconds. In testing, we were never able to trigger the bug in less than
25 seconds or so. Therefore, 10 seconds should be more than enough to
ensure that we never miss an advertisement.

Fixes: https://github.com/pybricks/support/issues/1096

This reverts commit 533ace06.

We will fix this a different way in a future commit.

This adds new defines for the Pybricks USB device class, subclass and
protocol. The class (0xff) is defined by the USB-IF and is the vendor-
specific class. The subclass and protocol are vendor-specific and come
from the first two bytes of the the Pybricks Bluetooth UUIDs.

This allows us to identify hubs running Pybricks when enumerating USB
devices.

This moves the USB VID/PID and strings into pbdrvconfig.h, so that each
hub can set the appropriate values. Additionally, since SPIKE Prime and
Robot Inventor use the same firmware, we have to dynamically set the
PID at runtime based on the hub variant.

Renames VCP (Virtual COM Port) functions to better reflect a Pybricks
custom class and makes global variables/functions static.

Also add a new header for the exported members.
Signed-off-by: Nate Karstens <nate.karstens@gmail.com>

We are using btstack as a submodule so this was out of date. Also we
aren't including any other submodules in this file, only vendored code.
So we can removed btstack to be consistent.

Removes the USB serial driver. A future change will add
functionality for a custom USB driver to implement the
Pybricks Profile instead.
Signed-off-by: Nate Karstens <nate.karstens@gmail.com>

Updates the STM32 USB library to tips. Removes the MIN & MAX #undefs
that were temporarily added in the previous patch.

The most important thing to note regarding compatibility is
that USBD_HandleTypeDef::pUserData is now an array.
Signed-off-by: Nate Karstens <nate.karstens@gmail.com>

Replaces the copy of the STM32 USB library with a submodule.
Uses v2.6.0 as that was roughly the version that was in the
repo. Temporarily adds #undef for MIN and MAX to get it to
compile. Removes the CDC file from the build as a subsequent
change will replace that with a custom class.
Co-authored-by: David Lechner <david@pybricks.com>
Signed-off-by: Nate Karstens <nate.karstens@gmail.com>

Nothing happens still, but at least you can run your program to test
and debug other portions of the code that do not rely on Bluetooth.

Also update the matching notes in the BLE module and remove City Hub
limitations which have been fixed.

See https://github.com/pybricks/support/issues/1096

MicroPython tests can run for only 10 seconds.

Make them work for current version of the drive base.

Remove prints since values are nondeterministic.

Use same ports as virtual hub.

The broadcast arg has been deprecated and is now the default.

Fix port to avoid conflict with Pybricks Code. Also fix image folder not existing.

Add some const-correctness to observed_data_t in a few places.

In the `ble` module, we maintain a copy of observed advertisement data
that is updated during servicing of PBIO (contiki) events. These events
can be triggered any time the GC is invoked, e.g. during allocation of
memory for MicroPython objects.

In pb_module_ble_observe(), we were iterating over the observed data
and allocating new MicroPython objects for each item which could trigger
PBIO events to be run resulting in the observed data being modified
while we are still iterating over it. This could result in a crash, the
most likely of which is raising an exception for an invalid data type.

We can avoid this by making a copy of the data before iterating over it.

Fixes: https://github.com/pybricks/support/issues/1278

This finishes up the REVISIT comment in start_broadcasting_task() to
actually wait for the set advertising data command to complete before
the task completes.

This fixes issues with calling the task too fast while the commands
from the previous call are still pending.

The timer was used to work around the issue but is no longer needed.

Fixes: https://github.com/pybricks/support/issues/1151

When broadcasting, the advertising parameters dont' change, so we only
need to set them once when we start broadcasting. This is done by
moving the code inside the if statement along with the enable function.

This changes the GAP discoverable parameters to limit connecting to
devices in a whitelist. Normally, when broadcasting, the hub should
not be connectable, but due to some quirks of the Bluetooth chip,
ADV_NONCONN_IND doesn't work under all circumstances and we have to use
ADV_IND which makes the device connectable. If another device connects
while broadcasting, it currently causes things to lock up. However,
we can prevent devices from connecting in the first place by enabling
the whitelist (which is empty).

This changes the command to update advertising data on the Bluetooth
chip in the broadcast task to use HCI_LE_setAdvertisingData() instead of
GAP_updateAdvertisingData().

It appears there is some sort of memory leak or some such on the
Bluetooth chip that causes it to lock up if we call the vendor-specific
GAP_updateAdvertisingData() too many times. It appears that we can work
around this by calling the standard Bluetooth command
HCI_LE_setAdvertisingData() instead.

GAP_updateAdvertisingData() would result in two events being sent back
from the Bluetooth chip, a status event and a command complete event.
With HCI_LE_setAdvertisingData() we only get a command complete event
back - with the TI vendor-specific opcode as if we had called
GAP_updateAdvertisingData().

Fixes: https://github.com/pybricks/support/issues/1095

Since efda5d02 ("drv/bluetooth_stm32_bluenrg: strict ordering of BLE
tasks"), it is no longer safe to call pbio_task_run_once() anywhere but
in the main contiki process loop of Bluetooth drivers.

This could break canceling some Bluetooth operations (causing them to
hang), but this will need to be fixed in a different way. A FIXME
comment with some suggestions is added to remind us to fix this.

This reverts commit a50ff187.

The Bluetooth drivers have task queues that prevent more than 1 task
from running concurrently.

The reverted change broke this safety mechanism by pumping tasks from
MicroPython causing multiple tasks to run at the same time, overwhelming
the Bluetooth chip.

We were always reading/writing 3 extra bytes because we weren't taking
into account the 3 extra bytes already sent for the header.

Also, real_write_xfer_size is unsigned and can be zero, so we should
not be subtracting from it.

Also, also, add some comments to clarify where the FCS (checksum) byte
comes into play.