0xFF won't switch MiP to app mode in firmware d160915 v1 bV0.6

[Tiogaplanet]

I have been developing the MiP_ProMini-Pack library by @adamgreen to connect an Arduino to MiP. While everything has been working for an older MiP with a firmware version string of "d220314 v0 bv2.3u" today I tried running it on a newer MiP with updated hardware (as evidenced by the Karin Group Bluetooth module) and a firmware string of "d160915 v1 bV0.6."

The '0xFF' command does not switch the newer MiP to app mode. It doesn't do anything at all. I tried sending a '0x00' which turns the chest LED green to indicate that MiP is in app mode but it doesn't respond to any other commands. The bare minimum code I'm using is this (copied from an earlier issue/post):

// Pin used by the TS3USB221A switch to connect the AVR UART to the MiP or PC.
// Set to HIGH, it selects the MiP.
// Set to LOW, it selects the PC.
#define MIP_UART_SELECT_PIN 2

void setup()
{
  pinMode(MIP_UART_SELECT_PIN, OUTPUT);
  digitalWrite(MIP_UART_SELECT_PIN, LOW);
  Serial.begin(115200);

  // Send 0xFF to the MiP via UART to enable the UART communication channel in the MiP.
  const uint8_t initMipCommand[] = { 0xFF };
  sendMessage(initMipCommand, sizeof(initMipCommand));
}

void loop() 
{
}

void sendMessage(const uint8_t* pMessage, uint8_t length)
{
  // Wait for any queued data destined to the PC to be transmitted and then switch the TS3USB221A switch 
  // to connect the AVR UART pins to the MiP.
  Serial.flush();
  digitalWrite(MIP_UART_SELECT_PIN, HIGH);

  // Send the specified bytes to the MiP via the UART.
  while (length-- > 0)
  {
    Serial.write(*pMessage++);
  }

  // Wait for that data to be transmitted and then set the TS3USB221A switch to connect the AVR UART pins back to 
  // the PC connection.
  Serial.flush();
  digitalWrite(MIP_UART_SELECT_PIN, LOW);
}

So my question is, did the UART commands change with this newer software version? Is there something new I could be doing to get this newer MiP to talk to the atmega328p?

Thanks in advance.

[Tiogaplanet]

Linking to @adamgreen's issue for same problem.

[adamgreen]

This issue is caused by the fact that the newer MiP robots use 9600 baud for the UART protocol instead of 115200 baud.