SIM900, работа через DEBUG Опции

[ap77]

Может кто сталкивался с такой проблемой.
В SIM900 EAT прошиваю простой тест (код ниже).
Работаю через DEBUG, скорость 115200, настройки порта стандартные.
Все посылки "туда" режутся по 4 символа (лог ниже).
Т.е. если послать строку 5 байт, 4 из них будут возвращены по прерыванию, а пятый символ "застрянет" в буфере до следующей посылки.
Первая плата такого глюка не имела, а вторая макетка стала вести себя так сразу после запуска.

Код

void fl_entry()
{
  bool  keepGoing = TRUE;
  FlEventBuffer  flEventBuffer;

  ebdat7_00EnterDebugMode();
  ebdat9_04SetUartdataToFL(TRUE);
  ebdat9_03SetModemdataToFL(TRUE);

  ebdat7_01DebugTrace( "test2\r\n");

  while (keepGoing == TRUE)
  {
    memset((u8*)&flEventBuffer,0x00,sizeof(flEventBuffer));
    eat1_02GetEvent(&flEventBuffer);
      
    switch(flEventBuffer.eventTyp) {
    case EVENT_MODEMDATA:  {
      flEventBuffer.eventData.modemdata_evt.data[flEventBuffer.eventData.modemdata_evt.length] = 0;
      ebdat7_01DebugTrace( "M:[%s]", flEventBuffer.eventData.modemdata_evt.data );
      break;
    }

    case EVENT_UARTDATA: {
      flEventBuffer.eventData.uartdata_evt.data[flEventBuffer.eventData.uartdata_evt.length] = 0;
      if ( DATA_SERIAL == flEventBuffer.eventData.uartdata_evt.type )    {
        ebdat7_01DebugTrace( "U:[%s]", flEventBuffer.eventData.uartdata_evt.data );
      }
      else {
        ebdat7_01DebugTrace( "D:[%s]", flEventBuffer.eventData.uartdata_evt.data );
        ebdat9_01SendToModem(flEventBuffer.eventData.uartdata_evt.data, flEventBuffer.eventData.uartdata_evt.length);
      }
      break;
    }

    case EVENT_INTR: {
      ebdat7_01DebugTrace("EVENT_INTR:\r\n");
      break;
    }
...

Включаю, подаю в порт DEBUG несколько раз строку "AT+CRWP=1\r\n"
Имею, такой лог:

Код

IIIIÿÿÿÿtest2
M:[
+CFUN: 1

+CPIN: READY
]EVENT_SERAILSTATUS:
M:[
Call Ready
]EVENT_SERAILSTATUS:
D:[AT+C]M:[AT+C]D:[RWP=]M:[RWP=]D:[1
A]M:[AT+CRWP=1
A]M:[1
A]D:[T+CR]M:[T+CR]D:[WP=1]M:[WP=1]D:[
AT]M:[
AT]D:[+CRW]M:[+CRW]D:[P=1
]M:[AT+CRWP=1
]M:[P=1
]D:[AT+]M:[AT+]D:[CRWP]M:[CRWP]D:[=1
]M:[AT+CRWP=1
]M:[=1
]D:[AT+C]M:[AT+C]D:[RWP=]M:[RWP=]D:[1
A]M:[AT+CRWP=1
A]M:[1
A]D:[T+CR]M:[T+CR]D:[WP=1]M:[WP=1]

В каком случае порт ввода\вывода может ограничивать длину ввода?

[Romashki]

Попробуйте вместо ebdat7_01DebugTrace, функцию ebdat7_02DebugUartSend с указанием длинны, потому что ebdat7_01DebugTrace определяет длину посылки по \r\n. На стр.49 документа SIM900_Embedded AT Application Note_V1.0.pdf описана эта функция.....
А промыли хорошо плату? Можно прозвонить ноги RX-TX между собой на проводимость.

[ap77]

Попробуйте вместо ebdat7_01DebugTrace, функцию ebdat7_02DebugUartSend с указанием длинны, потому что ebdat7_01DebugTrace определяет длину посылки по \r\n. На стр.49 документа SIM900_Embedded AT Application Note_V1.0.pdf описана эта функция.....
А промыли хорошо плату? Можно прозвонить ноги RX-TX между собой на проводимость.

Хорошо, попробую. Плату промывал, да. Ноги прозвонил, замыкания нет (и она бы не программировалась иначе).
Собственно вывод происходит нормально, если строку вывожу целиком программно.
Проблема именно при вводе. Во входном буфере поток "застревает".
UPD: Кстати, длину посылки эта функция определяет по завершающему 0, насколько понимаю. Входной параметр строка-константа, а завершитель у нее 0 ведь

[Romashki]

На стр.49 документа SIM900_Embedded AT Application Note_V1.0.pdf описана эта функция

[ap77]

На стр.49 документа SIM900_Embedded AT Application Note_V1.0.pdf описана эта функция

Да, спасибо.
там как-раз и написано: "In order to print from the beginning of a new line, the combination of \r\n will be used"