not getting serial data - esp32

not getting serial data means sometime UART_FIFO_OVF event occurs
here we can see when data is on uart at the second instant data length is showing 225bytes but when we print the data buffer its not showing the full data and UART_FIFO_OVF event occurs
do you have any suggestions on this to avoid this situation?
curr_data_len :225
uart data:$1,211,172,0,SENDDATA,1,1,1,G,HTTPGET,HTTPGET,SaveTicket?data=tkt|50609012023151839|506|195|1|3|6|1|1|3|257|1|0|0|0|0|24.00|0.00|0.00|0.00|0.00|0.00|0|24.00|09/01/2023|15:18:39|2|E261706111||0.00|0.00|0|0|50|552|10163|,14883
$0,OK,0,0,0,0,0,0,0,798*
curr_data_len :225
uart data:|0.00|0.00|0.00|0.00|0|24.00|09/01/2023|15:18:39|2|E261706111||0.00|0.00|0|0|50|552|10164|,14885
UART_FIFO_OVF

Related

Proper way of freeing buffers when using NdisSendPackets? (NDIS 5.0)

When using the simple case of NdisSend, I free the packet buffer and the buffer in case the returned status is not NDIS_STATUS_PENDING,
So what is the proper way of freeing the buffers that i Allocated with NdisAllocatePacket and NdisAllcateBuffer in the case of NdisSendPackets?
in the NdisSendPackets page, MSDN says:
"The caller of NdisSendPackets should test the returned status for each packet in such an array individually when its ProtocolSendComplete function is called with the completion Status"
But in the ProtocolSendComplete MSDN, it says:
"This function is a required driver function that completes the processing of a protocol-initiated send previously passed to NdisSendPackets or NdisSend, which returned NDIS_STATUS_PENDING."
So.. based on what i gathered, SendComplete is called only for packets that returned NDIS_STATUS_PENDING.
But why it says that i "should test the returned status " in the SendComplete, if its only for NDIS_STATUS_PENDING?!
The main problem I'm facing right now is that even tho I'm looping through every packet in the array after NdisSendPackets, and freeing only the ones that are not NDIS_STATUS_PENDING, i got a bugcheck at NdisFreeBuffer for "Attempt to free pool which was already freed" (BAD_POOL_CALLER), even tho I'm sure as hell i didn't free it before myself.. I moved all my buffer freeing to the SendComplete and i no longer get bugcheck, So it seems like my assumption was true and my SendComplete gets called for every packet, and not just the ones that return NDIS_STATUS_PENDING..
And another side question:
Do all NICs support multi packet send/recv? Is there any need for me to be worry when i use a packet array with NdisSendPackets and NdisMIndicateReceivePacket, instead of a single packet, or do all the NICs properly support multi packet send/recv?

How to store receiving SMS in GSM Module memory (SM or ME)?

I am using AI Thinker A7 GSM/GPRS/GPS Module demo v7.1.
I am trying to send and receive SMS through AI-Thinker Serial Tools V1.2.3.0
This module is working fine with making a call and receiving a call, sending and receiving an SMS. They work exactly fine.
The problem is that it does not store SMS in the memory?
I have done a lot of things to make it work, but there is no progress.
For instance, my AT commands and their responses are here,
AT+CPMS=?
+CPMS: ("ME","SM"),("ME","SM"),("ME","SM")
and
AT+CPMS="SM"
+CPMS: 0,35,0,35,0,25
and
AT+CPMS="ME"
+CPMS: 0,25,0,35,0,25
And I have tried CNMI settings like these,
AT+CNMI=1,1,0,0,0
OK
After these, I send msgs, and then tried to check through AT+CPMS and AT+CMGL, but there are no messages stored.
then I tried
AT +CNMI = 2,1,0,0,0
OK
and the same with
AT +CNMI = 2,2,0,0,0
OK
similarly
AT +CNMI = 0,1,0,0,0
OK
But still, I have not succeeded in getting message stored in memories.
Please help, if there are any other settings I need to do or my commands are wrong or my module doesn't support storing SMS (i highly doubt it since it has memory spaces which are showing that 25 SMS in SM, 35 in ME can be stored)??
If I understand your problem correctly, you are trying to read incoming SMS but can't list them.
Well, you need to understand that your GSM module doesn't store any incoming SMS by default. You have to command your GSM Module to store it. As you mentioned, you were very close to command for that. you need to command it this way:
AT+CPMS=mem1,mem2,mem3
AT+CPMS="SM","SM","SM"
As per documentation, you can mention three memories as the parameter for different operations like:
mem1 (in this example SM) - a memory from which messages are read and delete
mem2 (in this example SM; but could be ME) - a memory from which writing and sending operations are made
mem3 (in this example SM; but could be ME) - memory to which received messages are preferred to be stored
Now your GSM module will store all incoming messages into the SIM card and you'll be able to list all the messages with AT+CMGL=ALL
This way it worked for me.

Bypass message storage when sending SMS with AT commands

I have an array of Motorola Razar v3m's containg about 26 phones now. I have a multi-threaded software platform I built which manages each phone and message routing/timed-wait tasks and all of that.
When I issue:
AT+CMGW="1234567890"message<26><27>
It takes nearly 30 seconds to write the message to the phone memory, I then get send the message using:
AT+CMSS=messageIndex
and that takes another 30 seconds.
I have tried using AT+CMGS but can't get that functionality to send a message successfully at all.
I need this to be reliable, but with this method/phone combination, I wouldn't even depend on it to tell me Happy Birthday once a year.
Is there another way to send an SMS without storing it to memory first? Not only is it slow; but eventually causes the phone to no longer send messages at all, even if they are deleted after by AT+CMGD.
It sounds like the you are writing to the sim memory since it is so slow.
From the description of AT+CMGW in 27.005:
Execution command stores message (either SMS-DELIVER or SMS-SUBMIT) to memory storage <mem2>.
and earlier in "3.1 Parameter definitions":
<mem1> string type; memory from which messages are read and deleted (commands List Messages +CMGL, Read Message +CMGR and Delete Message +CMGD); defined values (others are manufacturer specific):
"BM" broadcast message storage
"ME" ME message storage
"MT" any of the storages associated with ME
"SM" (U)SIM message storage
"TA" TA message storage
"SR" status report storage
<mem2> string type; memory to which writing and sending operations are made (commands Send Message from Storage +CMSS and Write Message to Memory +CMGW) ); refer for defined values
The value of <mem1> and <mem2> is configured with AT+CPMS, preferred message storage (notice you should set both to the same value). So my guess is that if you run AT+CPMS? it will return +CPMS: "SM", ..., ..., "SM", .... If my guess is correct you should just switch to another storage on the phone ("ME", "MT" or "TA" - check with AT+CPMG=? what it supports (and it might support additional storages compared to the standard)) which will be much faster that the sim storage.
Using AT+CMGS should be possible, but notice that you do need to wait for "\r\n> " before sending the payload. When you say you did not get that one to work I assume you had some trouble with regards to proper parsing of the responses and proper waiting.

sendto() dgrams do not block for ENOBUFS on OSX

This is more of a observation and also a suggestion for whats the best way to handle this scenario.
I have two threads one just pumps in data and another receives the data and does lot of work before sending it another socket. Both the threads are connected via a Domain socket. The protocol used here is UDP. I did not want to use TCP as it is stream based, which means if there is little space in the queue my data is split and sent. This is bad as Iam sending data that should not be split. Hence I used DGRAM. Interestingly when the send thread overwhelms the recv thread by pumping so much data, at some point the Domain socket buffer gets filled up and sendto() returns ENOBUFS. I was of the opinion that should this happen, sendto() would block until the buffer is available. This would be my desired behaviour. However this does not seem to be the case. I solve this problem in a rather weird way.
CPU Yield method
If I get ENOBUFS, I do a sched_yield(); as there is no pthread_yield() in OSX. After that I try to resend again. If that fails I keep doing the same until it is taken. This is bad as Iam wasting cpu cycles just doing something useless. I would love if sendto() blocked.
Sleep method
I tried to solve the same issue using sleep(1) instead of sched_yield() but this of no use as sleep() would put my process to sleep instead of just that send thread.
Both of them does not seem to work for me and Iam running out of options. Can someone suggest what is the best way to handle this issue? Is there some clever tricks Iam not aware of that can reduce unnecessary cpu cycles? btw, what the man page says about sentto() is wrong, based on this discussion http://lists.freebsd.org/pipermail/freebsd-hackers/2004-January/005385.html
The Upd code in kernel:
The udp_output function in /sys/netinet/udp_usrreq.c, seems clear:
/*
* Calculate data length and get a mbuf
* for UDP and IP headers.
*/
M_PREPEND(m, sizeof(struct udpiphdr), M_DONTWAIT);
if (m == 0) {
error = ENOBUFS;
if (addr)
splx(s);
goto release;
}
I'm not sure why sendto() isn't blocking for you... but you might try calling this function before you each call to sendto():
#include <stdio.h>
#include <sys/select.h>
// Won't return until there is space available on the socket for writing
void WaitUntilSocketIsReadyForWrite(int socketFD)
{
fd_set writeSet;
FD_ZERO(&writeSet);
FD_SET(socketFD, &writeSet);
if (select(socketFD+1, NULL, &writeSet, NULL, NULL) < 0) perror("select");
}
Btw how big are the packets that you are trying to send?
sendto() on OS X is really nonblocking (that is M_DONTWAIT flag for).
I suggest you to use stream based connection and just receive the whole data on the other side by using MSG_WAITALL flag of the recv function. If your data has strict structure than it would be simple, just pass the correct size to the recv. If not than just send some fixed-size control packet first with the size of the next chunk of data and then the data itself. On the receiver side you would be wait for control packet of fixed size and than the data of size from control packet.

Server unable to receive byte data smoothly in vb6

I have a sender, a message forwarder which sends fix sizes of byte data at a rate of 5 milliseconds per message to my receiving program written in vb6, when I run the message fowarder and my receiving program on one machine, there's no issue but when they run on separate machines, the receiving program starts to experience some abnormalities.
e.g:
private sub socket_DataArrival(index as integer, ByVal dataTotal as Long)
Dim Data() as Byte
Length.Text = dataTotal
socket.GetData byteData, vbArray + vbByte
If Length.Text = "100" Then
txtOutput.Text = "Message1"
ElseIf Length.Text = "150" Then
txtOutput.text = "Message2"
End Sub
I will sometimes receive "2 in 1" message as in it comes in as 250 bytes or a non-recognizable byte size when I should be receiving either 100 or 150 only but if I reduce the sending rate to a slower speed say 50 milliseconds per message then it will be fine.
Can anyone provide with an advice? Thanks.
When sending data over a network you have to get used to the fact that the packets may arrive out of order, not promptly, not at all, etc.
You need to improve your message protocol to include a header that states which type of message follows. If order is important include a sequence number (I'm assuming you're using UDP). At present you are relying on timing to separate messages, which you cannot rely on over a network.
Buffer all your arriving data and handle it in chunks - the header allows you to tell what chunk size to use. Separate your input buffering from your message handling - use the DataArrival event to add data to the buffer, use a Timer or some other means of polling the buffer to check if it has messages ready to parse. Alas, this is VB6 so threading is not so easy. Take a look at The Common Controls Replacement Project timer object DLL if you need a Timer class that doesn't rely on a UI element being present.

Resources