gsm_core_lock problem

[vsanisimova]

Hi MaJerle!

I'm trying to use your library. I ported it to my project on stm32f4-discovery and started by debugging using your example code for message receiving. Here I faced a problem.

GSM initialization is successful, but the driver cannot configure the SIM card after that. The error appears when the command is sent to the producer_mbox queue. /* Check here if stack is even enabled or shall we disable new command entry? */ gsm_core_lock(); /* If locked more than 1 time, means we were called from callback or internally */ if (gsm.locked_cnt > 1 && msg->is_blocking) { res = gsmERRBLOCKING; /* Blocking mode not allowed */

(gsm.locked_cnt > 1 )=true (more often this variable is equal to 2) so res = gsmERRBLOCKING

I broke my head over this mistake, so I hope that you can help me

[MaJerle]

Did you call blocking api function when in protected area?

[vsanisimova]

I didn't. To be honest, I don't fully understand what you mean by protected area. I used your example from "sms_send_receive_thread_rtos_stm32f429zi_nucleo" folder. I only changed the parameters related to the device settings.

[MaJerle]

When you hit error, what is default and current command name? Check data variable in debugger.

This should not be the case. But lets see

[vsanisimova]

Default command is GSM_CMD_CPIN_SET, current command - GSM_CMD_CPIN_GET

[MaJerle]

So, to make it clear. If gsm.locked_cnt is greater than 1, then it means that API function has been called when core has been already protected. If API function would be called in blocking mode, it would enter dead-lock w/o return, so we have to prevent this.

Now what is unclear is what is the gsm.locked_cnt when you reach this statement to be true?

Some more debugging info would be great to have..some proactivity.

[vsanisimova]

I set a breakpoint on the _gsmi_send_msg_to_producermbox function. The first time _gsm.lockedcnt is greater than 1 (equal to 2) _msg->isblocking is 0, error isn't returned. At this moment _cmddef is _GSM_CMD_SIM_PROCESS_BASICCMDS, cmd is _GSM_CMDCNUM (_gsminit in process). After that _gsm_coreunlock() is performed and _gsm.lockedcnt reduced to 1.

When _configure_simcard function starts running _gsm.lockedcnt is already 2. So in _gsmi_send_msg_to_producermbox it increases to 3 and res becomes gsmERRBLOCKING.

Let me know if you need more information

Device STM32F407VG, 128K RAM, 1024K FLASH

[vsanisimova]

I found out that the counter increases when switching tasks. My project has 4 tasks: _gsm_threadproduce, _gsm_threadprocess, StartDefaultTask, and _usartthread.

StartDefaultTask initializes the gsm module, configures the SIM card, creates a queue for SMS. _Usartthread accepts responses from the module to the buffer and parses them.

After the _gsm_corelock is executed in the _gsm_threadproduce, the tasks are switched and the _usart_threa_d is started. The _gsm_corelock function is re-activated without calling _gsm_coreunlock at first. The lock counter reaches the value 2, and then 3.

I tried to switch thread priorities, but it didn't solve the problem: lower priority task delay higher priority task.

Are where some recommendations about task priorities for your library?

[MaJerle]

Are you sure that your mutex system functions work properly? Doesnt seem that they work if this is the result.