Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »

Related Jira Issues

FNSDKEXT-165 - Getting issue details... STATUS

FNSDKEXT-99 - Getting issue details... STATUS

USB Interface

  • Need confirmation on the following settings for COM port

    • Bit rate: 921600

    • Data bits: 8

    • Parity: None

    • Stop bits: 1

    • Flow control: None

    • Appears to work with these settings

    • Jabil [AK] (05/20/22): confirmed

  • Android USB Host/Accessory mode

    • When connecting to an Android device, is the VictoR device expecting the Android device to run in USB Host mode or USB Accessory mode?

      • Appears to work with Android device in Accessory mode?

      • Jabil [AK] (05/20/22): Android should be USB Host. [Disclaimer: Not tested with Android].

  • Disabling Bluetooth Link

    • When we disable the Bluetooth Link field of the General System Parameter characteristic of the Device Configuration Service, the Bluetooth connection to the device does not terminate. We cannot read data from the device over BLE at this point, but we can still write data over BLE. This includes re-enabling the Bluetooth link by writing to the General System Parameter characteristic again. Is this expected behavior? Should the device also terminate the connection when Bluetooth link is disabled? Will the device send data over USB if the Bluetooth connection is still active?

      • Yes, device appears to send data over USB even if BLE connection is still active, as long as Bluetooth link is disabled.

      • Jabil [AK] (05/20/22): Yes, this is expected current behavior and known issue we are tracking. We plan to turn off power to BT module instead and then connection will be terminated.

      • Jabil [AK] (05/20/22): The main processor (IMX) will consider Bluetooth disabled if above disable is done (or button 2 is pressed to disable BT) and will activate USB instead).

    • Sometimes when we disable the Bluetooth link, the VictoR device firmware appears to crash and then reboot after a few seconds. We do not lose Bluetooth connection during this process, but sometimes the buzzer gets stuck beeping during the process until the firmware has reinitialized. We are unable to read or write data over BLE while this is happening, but once it has reinitialized, it appears we can then read/write.

      • Jabil [AK] (05/20/22): This should be fixed already; we will verify and update you.

    • When we disable the Bluetooth link, if it doesn’t immediately crash and reboot the firmware, then when we re-enable it, we cannot receive data over Bluetooth unless we power cycle the device and reconnect.

      • Jabil [AK] (05/20/22): Bluetooth cannot be re-enabled over Bluetooth itself. Use button instead.

  • Reading/Writing over USB (Windows and Android)

    • If we write a read request and then read the response, the device firmware appears to crash and then reboot after a few seconds. This happens more often than not. There have only been a handful of times where we have been able to read multiple times without the device crashing.

  • Per Release Notes: “There is a transient failure with the initial USB tethering handshake.”

    • What is meant by “transient failure”? Does disconnecting and reconnecting resolve the issue?

      • Jabil [AK] (05/20/22): You may see errors from the serial port/file descriptor under high-bandwidth OTS operations due to buffer fill. These can be ignored and by backing-off the effort to write, they resolve themselves.

  • VictoR LED does not turn blue when connected over USB

    • Is this expected behavior? Should it turn blue the same as over BLE?

      • Jabil [AK] (05/20/22): No, it is only for BLE.

USB Message Structure

  • CRC calculation

    • Does the CRC include the header and the message payload, or just the message payload?

      • Based on testing it looks like it is header + message.

      • Jabil [AK] (05/20/22): The command CRC covers everything after the MAGIC first field.

  • Header / payload structure

    • ICD specified the following field in the header: 

      uint8_t data[MAX_DATA_LENGTH + sizeof(wasp_crc_t)];

    • We are interpreting this as, all data following the initial fields of the header are the payload, followed by the CRC. Is this correct?

      • Based on testing this appears to be correct.

      • Jabil [AK] (05/20/22): Correct.

    • We assume that message index is used to indicate which packet in a multi-packet message? For messages smaller than max packet size, can this always be 0? Is this correct?

    • We assume that message length is intended to be the number of bytes in the message payload not including header or CRC. Is this correct?

      • Jabil [AK] (05/20/22): Might also include CRC, need to verify.

        • Need an answer on this.

    • We assume that command id and command flags enums are one byte long? Is this correct?

      • Jabil [AK] (05/20/22): Correct.

  • Message payload sizing

    • Should the message payload buffer be sized to the largest payload size (max message data size+ crc size) or only sized to the actual message payload (current message data size + crc size)?

      • Seems like for requests it can be sized to the actual message.

      • For the response

        • Windows: Can be sized to the response.

        • Android: Must be sized to the maximum payload size.

      • Jabil [AK] (05/20/22): The largest payload size is used for high-performance transfer of data during the OTS process. For simplicity, you can use the largest payload buffer all the time, but you don’t need to for all other messages.

  • Read requests

    • When we send a read request, the response we get is always WASP_BT_CMD_SETATTR not WASP_BT_CMD_READ_RSP, is this expected?

      • Jabil stated in 05/20/22 meeting that data is continuously going out on the wire, so this might be data for something other than our read request. Need to continuously poll the read thread for data.

      • Even after doing this, we never seem to get a WASP_BT_CMD_READ_RSP on the wire.

    • Per the ICD, we are using the command WASTP_BT_CMD_READ_REQ for requests. There is also a WASP_BT_CMD_GETATTR command. What is this command intended for?

      • Jabil [AK] (05/20/22): It is intended to mirror the BT interface commands. The idea is either command can be used.

    • Sending a read request seems to be the specific message causing the firmware to crash. We are still unsure what in the message we are sending is causing the crash, and we are still not sure of the proper structure of a read request (see other outstanding questions). Either way, a malformed read request should not cause the device to crash. We would expect it to just reject the request.

    • Why do we have to specify attribute length for a request? Shouldn’t the firmware already know the length? This complicates our design as this isn’t needed for BLE.

  • Read response structure

    • How is a read response structured? Is the response message just the data bytes? Are there any attribute or offset fields like the read request?

      • Jabil [AK] (05/20/22): WASP_BT_CMD_READ_RSP command is a normal wasp_bt_cmd_t structure with all ‘data’ being the response payload. The attr-id is not sent back. The msg_index will match the corresponding request.

  • Write request structure

    • How is a write request structured?

  • Write response structure

    • How is a write response structured?

  • Subscribing to attribute changes

    • ICD states: “There is no need for notification registration; data will be pushed out during events in the same fashion as over BLE. [under review]”

    • However the ICD also states: “Subscription requests are sent with WASP_BT_SUBSCRIPTION command.”

    • Which statement is true?

    • Jabil [AK] (05/20/22): Some characteristics are already being pushed out on the wire by default without needing to register. WASP_BT_SUBSCRIPTION is intended for characteristics that are not already being pushed out on the wire.

  • Subscribe response structure

    • Is there a response to a subscribe request?

      • Jabil [AK] (05/20/22): Yes.

    • If there is a response, how is it structured?

      • Jabil [AK] (05/20/22): WASP_BT_CMD_RESULT

      • Need confirmation on this. Why is the structure different from read request/response?

    • What kind of response do we get when subscribing to an attribute that doesn't support subscribe?

  • General USB request/response flow

    • Are there any other messages besides attribute notifies/indicates that are sent out on the wire without a request having been sent?

      • Based on response to attribute subscription, answer is yes - some characteristics are always going out on the wire.

    • Are there any requests that do not provide a response?

  • Supported Services

    • Which services are supported by the USB interface?

    • Which characteristics of each service are supported?

Attachments

  File Modified
No files shared here yet.
  • No labels