Strange FCM behaviour investigation


#1

Interesting thing just found using Q2687 with 7.43 firmware and ADL FCM service (6.32 Open AT OS).
UART (1 or 2) subscribed as usual by adl_fcmSubscribe and switched to data mode. Data handler receive data notifications. But if incoming data block is exactly 56 bytes (no more, no less), notification is missing.

  • Transmit 56 bytes - no notification;
  • Transmit 56 bytes - no notification. Pause. Again 56 bytes - no notification. Pause. Again 56 bytes - handler receive 120 bytes and follow 48 bytes (so, all data OK, but buffered in module till 120 bytes UART buffer overflow).
  • Transmit 56 bytes - no notification. Transmit any other number of bytes - handler receive (56 + any) notification .

Is it known issue? Workaround? If not - I have to spend time to investigate further.


#2

How long is your “pause” :question:


#3

Seconds, minutes…


#4

Ok, first test results. Bug surely exists (details in my first post).
Checked old Q2687h and new RD modules with R7.43 firmware.

Simple test program used (+ terminal emulation software):

#include "adl_global.h"
#include "generated.h"

const u16 wm_apmCustomStackSize = 8192;
s8 ComHdl;

//_____________________________________________________
void UartOutStr(ascii* str)
{
  adl_fcmDataBlock_t* dataBlock = adl_memGet(sizeof(adl_fcmDataBlock_t) + wm_strlen(str));

  if(dataBlock)
  {
    dataBlock->DataLength = wm_strlen(str);

    wm_memcpy(dataBlock->Data, str, dataBlock->DataLength);

    switch(adl_fcmSendDataExt(ComHdl, dataBlock))
    {
    case OK:
    case ADL_FCM_RET_OK_WAIT_RESUME:
      // OK
      break;

    default: // ADL_RET_ERR_PARAM, ADL_RET_ERR_UNKNOWN_HDL, ADL_RET_ERR_BAD_STATE:
      adl_memRelease(dataBlock);
    }
  }
}

//_____________________________________________________
static bool ComCtrlHandler(u8 event)
{
  switch(event)
  {
  case ADL_FCM_EVENT_FLOW_OPENNED:      // (related to adl_fcmSubscribe),
    adl_fcmSwitchV24State(ComHdl, ADL_FCM_V24_STATE_DATA);
    break;

  case ADL_FCM_EVENT_FLOW_CLOSED:       // (related to adl_fcmUnsubscribe),
    adl_atSendResponse(ADL_AT_PORT_TYPE(ADL_PORT_UART1, ADL_AT_INT), "\r\nUART in command mode\r\n");
    break;

  case ADL_FCM_EVENT_V24_DATA_MODE:     // (related to adl_fcmSwitchV24State),
    UartOutStr("\r\nUART in data mode\r\n");
    break;

  case ADL_FCM_EVENT_V24_AT_MODE:       // (related to adl_fcmSwitchV24State),
    adl_fcmUnsubscribe(ComHdl);
    break;
  }

  return TRUE;
}

//_____________________________________________________
static bool ComDataHandler(u16 datalength, u8 *data)
{
  ascii str[32];

  // Switch to AT-mode by escape char
  if((datalength == 1) && (*data == 0x1B)) adl_fcmSwitchV24State(ComHdl, ADL_FCM_V24_STATE_AT);
  else
  {
    wm_sprintf(str, "%u bytes received\r\n", datalength);
    UartOutStr(str);
  }

  return TRUE;
}

//_____________________________________________________
void main_task ( void )
{
  adl_atSendResponse(ADL_AT_PORT_TYPE(ADL_PORT_UART1, ADL_AT_INT), "\r\nFCM test startup\r\n");

  if(adl_fcmIsAvailable(ADL_PORT_UART1))
  {
    ComHdl = adl_fcmSubscribe(ADL_PORT_UART1, ComCtrlHandler, ComDataHandler);

    if(ComHdl < 0) adl_atSendResponse(ADL_AT_PORT_TYPE(ADL_PORT_UART1, ADL_AT_INT), "\r\nError FCM subscribe\r\n");
  }
  else adl_atSendResponse(ADL_AT_PORT_TYPE(ADL_PORT_UART1, ADL_AT_INT), "\r\nUART unavailable\r\n");
}

Such error… Its not good. Not good at all.


#5

Good news!
Just tested 2.34 package (7.44 firmware + 6.34 OS). Error looks fixed.


#6

IS the error documented at all?

What versions were affected?


#7

No. Not mentioned in 7.44 FW release notes. I think, its rather ADL bug, but OS 6.34 release notes contains no information on the changes. :slight_smile:
Just can’t reproduce error with new release.