Receiving only one char through uart interrupt in Serial_uartes

[umrsraj]

Hi there,

I'm using nrf52840 DK and Custom board, SDK 15.1.0, Segger Embedded Studio(SES v5.20)

my issue is when i receive data from uart interrupt based on serial uartes example, i can only receive one char at a time. that means if i store that data in a char variable and should add to the char array then its works fine, but i want to read the complete data on single shot, so how can i do that,? i'm i doing anything wrong.

void GSM_InterruptHandler(nrf_serial_t const *p_serial, nrf_serial_event_t event)
{
static uint8_t index1=0;
char bb;
switch (event)
  {
    case NRF_SERIAL_EVENT_RX_DATA:
      if((nrf_serial_read(&serial0_uarte, &bb, sizeof(bb), &readed_size, 500))==NRF_SUCCESS)
      {
      gsm_d.RxBuf[index1++] = bb;
      rx_done = true;
      }
      break;
    case NRF_SERIAL_EVENT_TX_DONE:
      tx_done = true;
      break;
    case NRF_SERIAL_EVENT_DRV_ERR:
      APP_ERROR_CHECK(nrf_serial_uninit(&serial0_uarte));
      APP_ERROR_CHECK(nrf_serial_init(&serial0_uarte, &m_uarte1_drv_config, &serial0_config));
      break;
    case NRF_SERIAL_EVENT_FIFO_ERR:
      break;
    default:
      break;
  }
}

Im reading the rx buff like this, but its triggers multiple times for every rx event, and i need like this

case NRF_SERIAL_EVENT_RX_DATA:
      if((nrf_serial_read(&serial0_uarte, &gsm_d.RxBuf, sizeof(gsm_d.RxBuf), &readed_size, NRF_SERIAL_MAX_TIMEOUT))==NRF_SUCCESS)
      {
      rx_done = true;
      }
      break;

so please help me

Thanks in advance

Best Regards

Raj

[Susheel Nuguru]

I could not take a look at this before the easter holiday, i will take a look at this early next week when i come back to office.

[umrsraj]

Hi susheel,

ok we can wait till next weeek, but please make sure to complete ASAP

Best Regards,

Raj

[Susheel Nuguru]

Hi Rajender, I am back from vacation and will look into this tomorrow. I suspect that the issue is that GSM_InterruptHandler might have higher priority than UART interrupt and is triggering faster than the byte received inthe UART RX FIFO. Or the uart traffic is slower than the frequency of the GSM interrupt frequency?

if none is the case, then we need to debug as to why you are not able to receive multiple received bytes from FIFO.

Before i can try to dig more into the nrf_serial library, could you tell me 

1) GSM interrupt frequency
2) UART characters on the RX line in single transaction (logic analyzer snapshots would be helful)
3) UART and GSM interrupt priority

[umrsraj]

Hi Susheel,

1) GSM Interrupt occurs when we request the data from gsm like sending any AT command to the GSM (most likely around 1 second)

2) RX Characters on the RX line --> i dont have the Logic analyser(CRO) in with me but i can say minimum RX characters are "OK"-2 characters,  MAX characters are around 255 characters.

3)If we talk about any interrupt priority, i have not changed any interrupt priority its default as the example only (Mostly Priority 7)

I am not sure my answers are correct as you expected but please help and correct me.

Best Regards

Raj.  

[umrsraj]

Hi susheel,

I know i have given very late replay last time, im sory for that but i need to solve this issue ASAP, this issue effecting the complete project development so please replay soon.

Please understand the urgency.....

Best Regards,

Raj

[Susheel Nuguru]

Hi Rajender.

I have now looked into the nrf_serial implementation and it is possible that you are using UART configuration instead of UARTE. Can you please attach your sdk_config.h (best would be to attach your project here) so that i can quickly review the peripheral configuration you are using?

[umrsraj]

serial_uartes - GSM(sms).zip

Hi Susheel,

Thanks for the reply,

Here i am attaching zip file of my project, i think you can work around with this,

and my problem in this project are,1) taking bunch of data at single shot only, 2)Response of GSM module was not catching completely (ex: if it should say, "\r\nOK\r\nCONNECT\r\n", Its saying "\r\nOK\r\nCONN"

Please check on the issue for data loss alos

Best Regards,

Raj.