Serial communication: gina_serdev_read() returning -1 and no data | Telit Cinterion IoT Developer Community
June 22, 2021 - 3:53am, 1958 views
I am using the SDK to develop an app in C to read and write on the serial (ASC1).
For that, I've followed the examples found in SDK, however, I am having an issue.
Basically, I have these steps:
- gina_serdev_open() for ASC1
- gina_serdev_ioctl() to register the callback for the serial device events
- at the serdev callback, I use this tx_event_flags_set() to set the corresponding event: GINA_SERDEV_CB_DATA_AVAILABLE;
- busy waits in a while(1) loop for: tx_event_flags_get(..., TX_WAIT_FOREVER);
- sends data to the Module via ASC1
- this will cause the tx_egent_flags_get() to return the bit set to read data from uart
- read data gina_serdev_read();
- print data in DEBUG interface (ASC0)
- loop again to tx_event_flags_get(..., TX_WAIT_FOREVER);
When I write data on ASC1, the code calls the registered uart callback, sets the corresponding flag, which causes the code to read data via gina_serdev_read(), but it is returning -1 and no data is seen.
Since the code is an infinite loop, after reading data (error), it starts again waiting for the next event.
At this point, it never passes again the tx_event_flags_get(..., TX_WAIT_FOREVER);
Even though I am sending more data.
Am I missing something?
Is there a way to verify why gina_serdev_read() returned -1? Similar to "errno" or something.
BTW, I am using the TX_OR_CLEAR flags.
i.e: tx_event_flags_get(ctx->events_flag, event_mask, TX_OR_CLEAR, &event, TX_WAIT_FOREVER);
Hello,
Did you modify anything or it is an original example?
BR,
Bartłomiej
It is modified because we are developing the firmware for a product we are working on.
The logic from the original example was kept the same. The only difference is that we have separated C files for separated rules.
For example, we have a C file called event_handler.c which is in charge of handling the events that can occur in the module, so, it has the func:
tx_event_flags_get(ctx->events_flag, event_mask, TX_OR_CLEAR, &event, TX_WAIT_FOREVER);
And, then, when the event occurs, it verifies what event just happened via if (event & BIT_blabla), etc.
Following, it returns the next state of the main state machine we have, for example, STATE_READ_SERIAL if the event was from serial.
The state machine loops infinitely transitioning over the states according to the events that happen (managed by the event_handler.c).
Thus, it calls the read_serial() from our uart.c file (which is a wrapper for the gina API).
I just did a new test now, where I put the gina_serdev_read() within the event_handler.c inside the if (event & SERIAL_DATA_RECEIVED) {} statement.
Then, the read operation works fine.
Although this solves the problem, I still don't know what caused it, and besides that, this solution (having the read happening within event_handler context) breaks the design pattern we are using for development.
I suspect it could be something related to the stack of the module or something.
Do you know what could be causing this, or, how could I investigate further the root cause?
Thank you.
Hello,
I'm sorry but I don't have an experience with this topic yet, so I forwarded this question to an expert. But didn't receive any feedback yet.
This function should returns the number or bytes read or 0 if there's no data to read. Have you checked err for read errors?
BR,
Bartłomiej
Hello,
If this problem is not solved yet, could you send me the complete code? I'll send it to the expert so he could check.
Thanks,
Bartłomiej
Sorry for my late reply.
While continuing the development of the app I was working on, I managed to solve it.
Actually, a lot has been developed, so I am not 100% sure what fixed this issue.
But I believe that the issue was that I had created one extra event_flag for the UART, and I was using the global event_flags_set to handle the UART. So, the tx_event_flags_set() was being called in the extra event_flag for UART, while I was expecting it to be set in the global event_flags_set.
Thus I conclude it was a bug done by myself. Because I am using separated C files to develop, I had messed up this part somehow.
But to conclude, not the UART is working as I expected it to be.
Thank you for getting back to this and posting the conclusion.
It's good to read that the problem was solved.
This probable cause really sounds reasonable.
Best regards,
Bartłomiej