8 years, 10 months ago.

All MTSSP Pipes Returning Same Data

Follow up (sorry if you are receiving this for the second time - I initially posted these questions in the comments of the answer to my last question, but realized that no one might be notified):

I am having trouble implementing the protocol to receive data, here: Message transfer/receive protocol clarification. I am definitely receiving data from the MTi-3 (specifically, I am using the dev kit). However, the data that I receive, and the readData results are also most certainly incorrect (results below):

static void readData(uint8_t pipe, uint16_t dataLength) {
  if (debugMsg) Serial.println("reading data");
  
  const int mtsspHeaderLength = 2;
  uint8_t* buff = (uint8_t*) allocateDataBuff(dataLength + mtsspHeaderLength);
  if (buff) {
    uint8_t* dptr = buff;
    // MTSSP abbreviated message does not include this part of the header
    // Manually include them so that XbusParser can parse message correctly
    *dptr++ = XBUS_PREAMBLE;
    *dptr++ = XBUS_MASTERDEVICE;

    // Request to read from specified pipe, add to buffer
    digitalWrite(pin_chipSelect, LOW);
    sendOpcode(pipe);
    for (int i = 0; i < dataLength; ++i) {
      *dptr++ = SPI.transfer(BLANK);
    }

    digitalWrite(pin_chipSelect, HIGH);
    
    printBuffer(buff, dataLength);         // Debug message

    //int temp = XbusParser_parseBuffer(parserManager, buff, dptr-buff);
    //Serial.println(temp); // Debug for making sure it is entering buffer
    XbusParser_parseBuffer(parserManager, buff, dptr-buff);
    deallocateDataBuff(buff);
  }
}


void dataReadyHandler(int event, int param) {
  // if (debugMsg) Serial.println("In dataReadyHandler...");

  //while (true) {
    digitalWrite(pin_chipSelect, LOW);
    // Determine if and how much noitification-/measurement- data is available
    sendOpcode(XBUS_PIPE_STATUS);
    
    // MtsspConfiguration message format as follows, all data little endian:
    //  uint16_t m_notifcationMessageSize;
    //  uint16_t m_measurementMessageSize;
    uint8_t pipeStatus[4];
    for (int i=0; i < sizeof(pipeStatus); ++i) {
      pipeStatus[i] = SPI.transfer(BLANK);
    } // Read pipe status header
    digitalWrite(pin_chipSelect, HIGH);

    uint16_t notificationSize = (pipeStatus[1] << 8) | pipeStatus[0];
    uint16_t measurementSize = (pipeStatus[3] << 8) | pipeStatus[2];

    if (debugMsg) {
      Serial.println("Notification size, measurement size: ");
      Serial.println(notificationSize, HEX);
      Serial.println(measurementSize, HEX);
    }

    // If message present, read from appropriate pipe
    if (notificationSize) {
      //readData(XBUS_NOTIFICATION_PIPE, notificationSize);
      readData(XBUS_NOTIFICATION_PIPE, pipeStatus[0]);
    } else if (measurementSize) {
      // readData(XBUS_MEASUREMENT_PIPE, measurementSize);
      readData(XBUS_MEASUREMENT_PIPE, pipeStatus[2]);
    }// else break;
  //}
}

/*
 * XbusParser callback function for handle received messages
 * Examines pointer to last reeived message to identify message type
 * Copy messages into one of two message queues for later handling by main thread
 */
static void messageHandler (struct XbusMessage const* message) {
  XbusMessage* m = (XbusMessage*) allocateXbusMessage();
  if (m) {
    memcpy(m, message, sizeof(XbusMessage));
    if (message->mid == XMID_MtData || message->mid == XMID_MtData2)
      dataInQueue.push(m);
    else
      responseQueue.push(m);
  } else if(message->data) {
    Serial.print("Unknown MID: ");
    Serial.println(message->mid);
    deallocateDataBuff(message->data);
  }
}

For example, the results I receive are: notificationSize = 0x2BF8, measurementSize = 0xFFA6 (These values remain the same in each given run, but if I power cycle the dev kit, sometimes I get different values)

Pipe Message Sizes Too Large

These values do not make any sense. These message lengths should not be this large. For MtData type, which is used by the MTi-1 series (the code provided by Xsens only specified MtData2 type), the maximum size is 254 bytes. I have created my buffer to be that large. The notification and measurement sizes should be within that range, but of course they are not. Why is that? What are these values actually corresponding to?

All Pipes are Returning Same Values

I tried to proceed and see how the sensor would react by only passing in the lower byte of each message size, i.e. 0x81 and 0x14 (see code lines 61 and 65). The values returned by readData, as debugged using printBuffer, show that the first four bytes (at the very least) returned by the sensor (after the opcode and three filler bytes sent) are all the same. When I try to read the buffer, I get the following: FA FF F8 2B A6 FF 5E 3B.... The first two bytes, FA and FF were manually placed into the buffer by me (the preamble and BID). Notice that the next four bytes, F8 2B A6 FF are the same values as the message "sizes" that I received (not placed in little endian). When I read from the measurement pipe, I receive the exact same bytes as I when I read from the notification pipe. This leads me to believe that I am reading the same message from every single pipe. What would cause this?

The only possible reason I can imagine right now is that somehow it is sending me an error message of sort, because perhaps I have not configured it properly? Would this be caused because I have not woken up the device yet? I have the wakeup sequence in place, but of course it does not receive the proper MID, it receives the bytes as described above, none of the first 10 bytes which correspond to any known MID. Again, what might the issue be?

Brief Summary of My Process

• Data ready pin goes high, ISR triggered
• ISR adds data ready event to queue
• Event handler determines message size
  • As mentioned above, message size read is incorrect
• Data is read into buffer and parsed
  • The data read into buffer is gibberish
  • Data is being parsed by buffer, but obviously it does not recognize it
• XbusParser callbacks message handler
• Message handler adds message to message queue
• Main loop continually checks message queue, (right now, just prints when message queue has item)

Last question: What data does the MTi send if it is asked to transfer data, but no opcode was given? Or the master tries to read more data than the actual message length?

Question relating to:

Last updated: 02 Oct 2015

2 53

/ Xbus

Basic implementation of Xbus message parsing and generation for embedded processors. The code has no dependencies and should also work for other MCU architectures than ARM provided a C99 compiler …