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 23 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?

  • 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?

    • 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?

    • The response we receive when requesting a read contains much more data than we would expect. For example, when reading battery level, a 1 byte attribute, we get a response with a message length reported as 176 bytes long in the response header. We are not sure how to interpret this data as we are unsure of the structure of a read response. See the Read response structure questions below. We are also unsure if the data is valid because there appears to be a lot of garbage data in the message after the header. See the output below:

      • Request sent:

        byte[] readRequestBuffer = new byte[4+2+1+1+2+2+2+2+2+4];
using (var memoryStream = new MemoryStream(readRequestBuffer))
{
    using (var writer = new BinaryWriter(memoryStream))
    {
        // header
        writer.Write(0xee75aac0); // magic number start delimiter | 4 bytes
        writer.Write((ushort)0);  // message index                | 2 bytes
        writer.Write((byte)6);    // read request command id      | 1 byte
        writer.Write((byte)0);    // command flags (not used)     | 1 byte
        writer.Write((ushort)6);  // message length               | 2 bytes
        writer.Write((ushort)0);  // mtu (not used)               | 2 bytes

        // request
        writer.Write((ushort)4609); // current battery level attribute id   | 2 bytes
        writer.Write((ushort)1);    // length of current battery level data | 2 bytes
        writer.Write((ushort)0);    // offset (not used)                    | 2 bytes

        // crc
        uint crc32 = Crc32Algorithm.Compute(readRequestBuffer, 0, readRequestBuffer.Length - 4);
        writer.Write(crc32); // crc | 4 bytes
    }
}

      • Response received:

          Data[0]: 192 // c0
  Data[1]: 170 // aa
  Data[2]: 117 // 75
  Data[3]: 238 // ee
  Data[4]: 62  // msg index byte 1
  Data[5]: 3   // msg index byte 2
  Data[6]: 2   // wasp bt cmd setattr
  Data[7]: 0   // cmd flags
  Data[8]: 176 // msg length
  Data[9]: 0   // mtu
  Data[10]: 0
  Data[11]: 0
  Data[12]: 1
  Data[13]: 67
  Data[14]: 151
  Data[15]: 172
  Data[16]: 100
  Data[17]: 217
  Data[18]: 128
  Data[19]: 1
  Data[20]: 119
  Data[21]: 219
  Data[22]: 103
  Data[23]: 62
  Data[24]: 97
  Data[25]: 166
  Data[26]: 92
  Data[27]: 190
  Data[28]: 198
  Data[29]: 136
  Data[30]: 28
  Data[31]: 65
  Data[32]: 215
  Data[33]: 59
  Data[34]: 181
  Data[35]: 187
  Data[36]: 216
  Data[37]: 173
  Data[38]: 128
  Data[39]: 60
  Data[40]: 219
  Data[41]: 191
  Data[42]: 105
  Data[43]: 187
  Data[44]: 176
  Data[45]: 204
  Data[46]: 50
  Data[47]: 193
  Data[48]: 148
  Data[49]: 153
  Data[50]: 10
  Data[51]: 66
  Data[52]: 206
  Data[53]: 76
  Data[54]: 70
  Data[55]: 66
  Data[56]: 2
  Data[57]: 162
  Data[58]: 254
  Data[59]: 62
  Data[60]: 73
  Data[61]: 29
  Data[62]: 142
  Data[63]: 59
  Data[64]: 177
  Data[65]: 123
  Data[66]: 114
  Data[67]: 188
  Data[68]: 135
  Data[69]: 15
  Data[70]: 94
  Data[71]: 63
  Data[72]: 0
  Data[73]: 0
  Data[74]: 0
  ...
  Data[511]: 0

  • 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?

  • Subscribe response structure

    • Is there a response to a subscribe request?

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

    • 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?

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

Attachments

  File Modified
No files shared here yet.
  • No labels