Fix T1000-E application reporting the bootloader's USB product name - #3226
Open
michaeljensen wants to merge 1 commit into
Open
Fix T1000-E application reporting the bootloader's USB product name#3226michaeljensen wants to merge 1 commit into
michaeljensen wants to merge 1 commit into
Conversation
boards/tracker-t1000-e.json set the application's usb_product to "T1000-E-BOOT". PlatformIO's nordicnrf52 builder turns that key into -DUSB_PRODUCT, which lands in the USB device descriptor, so a running node enumerates as "T1000-E-BOOT" while the Seeed bootloader enumerates as "T1000-E". The firmware that is not the bootloader is the one wearing the bootloader's name. That misidentification is load-bearing in the web flasher. flasher.meshcore.io calls navigator.serial.requestPort() with no filters, so the row label in the browser's port chooser -- which the browser builds from the USB iProduct string -- is the only signal the user has. The nRF52 flow prompts twice, once for the 1200-baud DFU touch and again for the flash itself, with no re-enumeration watcher in between, and at that second prompt the two candidate rows read: T1000-E-BOOT (239a:8029) <- the application T1000-E (2886:0057) <- the actual bootloader which is backwards at the moment the user has to tell them apart. The same define is also the Adafruit core's CFG_DEFAULT_NAME, so it is what a companion advertises over BLE whenever the intended name is too long for the GAP device-name attribute and setName() silently fails (meshcore-dev#1769). The string is user-visible over Bluetooth as well. Name the application after the firmware it runs rather than after the board. This deliberately differs from the hardware-name convention in the other nRF52 board files ("WisCore RAK4631 Board", "Seeed Wio Tracker L1") because the string's job here is to distinguish the running application from a bootloader that will never claim to be MeshCore; "Seeed T1000-E" would sit one word away from the bootloader's "T1000-E". Upload and flashing are unaffected -- PlatformIO's port autodetect matches on hwids (VID:PID), not on this string. On Linux the /dev/serial/by-id symlink does change, from usb-Seeed_Studio_T1000-E-BOOT_<serial>-if00 to usb-Seeed_Studio_MeshCore_T1000-E_<serial>-if00, so anything pinned to the old path needs updating.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
boards/tracker-t1000-e.json set the application's usb_product to "T1000-E-BOOT". PlatformIO's nordicnrf52 builder turns that key into -DUSB_PRODUCT, which lands in the USB device descriptor, so a running node enumerates as "T1000-E-BOOT" while the Seeed bootloader enumerates as "T1000-E". The firmware that is not the bootloader is the one wearing the bootloader's name.
That misidentification is load-bearing in the web flasher. flasher.meshcore.io calls navigator.serial.requestPort() with no filters, so the row label in the browser's port chooser -- which the browser builds from the USB iProduct string -- is the only signal the user has. The nRF52 flow prompts twice, once for the 1200-baud DFU touch and again for the flash itself, with no re-enumeration watcher in between, and at that second prompt the two candidate rows read:
T1000-E-BOOT (239a:8029) <- the application
T1000-E (2886:0057) <- the actual bootloader
which is backwards at the moment the user has to tell them apart.
The same define is also the Adafruit core's CFG_DEFAULT_NAME, so it is what a companion advertises over BLE whenever the intended name is too long for the GAP device-name attribute and setName() silently fails (#1769). The string is user-visible over Bluetooth as well.
Name the application after the firmware it runs rather than after the board. This deliberately differs from the hardware-name convention in the other nRF52 board files ("WisCore RAK4631 Board", "Seeed Wio Tracker L1") because the string's job here is to distinguish the running application from a bootloader that will never claim to be MeshCore; "Seeed T1000-E" would sit one word away from the bootloader's "T1000-E".
Upload and flashing are unaffected -- PlatformIO's port autodetect matches on hwids (VID:PID), not on this string. On Linux the /dev/serial/by-id symlink does change, from usb-Seeed_Studio_T1000-E-BOOT_-if00 to usb-Seeed_Studio_MeshCore_T1000-E_-if00, so anything pinned to the old path needs updating.