I am using BC66 with OpenCPU and sometimes I have problems with Tx.
After starting the application I have to do some tasks, so after these tasks, I send data by UDP to my server. It seems to be, that sometimes, when I try to send the UDP data with the function RIL_SOC_QISEND (By OpenCPU: ril_socket.h [SDK v1.5]), the Tx fails and I think is due to the module is in RCC_IDLE state.
So, What can I do to force the module to be in RCC_CONNECTED before to execute the function RIL_SOC_QISEND to make sure that the TX is going to be ok?
The function returns the error number -1. Remember that I am using OpenCPU.
ret = RIL_SOC_QISEND(CONNECT_ID, data_length, send_data);
if (ret != RIL_AT_SUCCESS) {
APP_DEBUG(prt_debug, "[ERROR] Send data: %d\r\n", ret);
}
It seems to be the device at that moment is in the status RCC_IDLE. So this is the reason I would like to force the device to be in RCC_CONNECTED mode before to try a UDP sent.
When the application starts, I execute: Ql_SleepDisable().
After executing the function: RIL_SOC_QISEND() correctly, I finished my application an execute: Ql_SleepEnable() in order to go to deep sleep and PSM.
So during the execution of the function RIL_SOC_QISEND, the module canât go to idle or deep sleep, but I think somehow the module (the RF part) is not in the status RCC_CONNECTED:
Not Always. Only from time to time, so itâs very difficult to get the error. When I get this error I wait for 2.5 seconds, and close de socket [1] and open the socket [1] and send the UDP package again⊠Some times works to retry and sometimes it doesnât work. I try this process only 3 times. If it fails, I cancel sending the UDP package.
[1] I know that with UDP it is not necessary to open and close the socket, due to the fact it is a protocol not oriented to connection, but I try to have everything compatible with TCP/IP, in case I need to move from UPD to TCP/IP.
Hi Oscargomezf
Confirm whether you execute the RIL SOC_SEND () function, whether there are other AT instructions in the RIL library being executed, if there are, your current problem will occur.
Thanks in advanced for your help. I appreciate your effort with all my issues.
Is there anyway to check this:Confirm whether you execute the RIL SOC_SEND () function, whether there are other AT instructions in the RIL library being executed?
I have several task, so this issue could be happening.
I thought, if someone gets the control of the RIL (UART), there is a semaphore or other mechanism to block others⊠Do you know if this mechanism exists?
Hi Oscargomezf
This is the module kernel code, there is no problem.
Please also confirm your code logic, the calls to the ril interface must not conflict.
You cannot send AT commands to the kernel at the same time.
I donât understand what you mean with this: âthe calls to the ril interface must not conflict.
You cannot send AT commands to the kernel at the same time.â
In all the functions I am using related to AT commands, this function is involved: Ql_RIL_SendATCmd, so due to the semaphore: âm_nAtMutexIdâ, I am not going to access to the UART port at the same time, arenât I?
The point is, if I try to access the UART port in two different tasks at the same task, this semaphore is going to deal with the potential problem. Am I right?
1Âș. Then you mean, not to access to the Ql_RIL functions at the same time you are using the UART. In my case, I am only using the uart port for printing messages, that is to say:
[Module Tx] ----> [Rx Console PC]
Therefore, I am not accessing at the same time to the physical UART and the logical UART.
2Âș. I am very concerned about this: " UDP have issues in firmwares BC66NBR01A07 and 10":
Are there any UDP errors in FW BC66NBR01A10? Do you know what kind of errors or what they are related to? We are thinking to launch a product with this FW.
1.NO⊠you will have access to Ql_UART(used kernel serial driver) and Ql_RIL (VIRTUAL_PORTx⊠is a pipe to modem)
example: you can âprint/debugâ lines from AT_RIL_CALLBACK
I have problems with dns_resolve_address ( is UDP protocol ) sometimes it works, sometimes it doesnât⊠timeoutâŠ
1Âș. According to 1: Ok, Yes I am using Ql_UART_Write for printing debug messages and Ql_RIL_SendATCmd for sending commands to the module (through a pipe). So, you mean that the mutex in the function Ql_RIL_SendATCmd:
Ql_OS_TakeMutex(m_nAtMutexId, 0xffffffff);
It is not enough and I have to make sure not to execute this function: Ql_RIL_SendATCmd twice at the same time, donât I?
2Âș. According to: "I have problems with dns_resolve_address ( is UDP protocol ) sometimes it works, sometimes it doesnât⊠timeoutâŠ"
The task I execute in the module usually lasts only 15 seconds, but sometimes Iâve noticed that it lasts much more, between 80-130 seconds, Could it be related this issue to the problem with dns_resolve_address?
