SMTC_MODEM_HAL_PANIC macro usage in not critical conditions

[sca-l]

Hi,

I noticed that there are about 210 calls of Macro SMTC_MODEM_HAL_PANIC. Many of this cases are not critical conditions, in my opinion, to justify a drastic reboot operation. Can I know which is the reason for this approach, please? Did I miss something in my thought?

Regards and thank you for the support, Laura Scalzo

[opeyrard]

Hi, The use of SMTC_MODEM_HAL_PANIC is justified as this prevent from staying in a wrong setup/configuration. Could you please provide some examples where the use of SMTC_MODEM_HAL_PANIC should not be justified ? We will take this into consideration as continuous improvement for the next coming releases. Many thanks,

[sca-l]

Hi,

thank you for the comment. I know in some cases it is necessary, but, for me, not in these all cases. For example, if a task expires and it is in Running state, I think that the RP should only Abort the task to recover the situation. In my opinion, it is not necessary to reboot the device with consequent rejoin phase and other operations. I'm referring to these following lines:

void rp_callback( radio_planner_t* rp ) { if( ( rp->tasks[rp->radio_task_id].state == RP_TASK_STATE_RUNNING ) && ( rp->disable_failsafe != RP_DISABLE_FAILSAFE_KEY ) && ( ( int32_t ) ( rp->tasks[rp->radio_task_id].start_time_ms + 128000 - smtc_modem_hal_get_time_in_ms( ) ) < 0 ) ) { SMTC_MODEM_HAL_PANIC( "RP_FAILSAFE - #%d\n", rp->radio_task_id ); }

I don't know if you are agree, but I thing it should be a case in which reboot is not necessary.

There is another example related to CAD operations. Also in this case I think it should not necessary.

if( rp_task_enqueue( relay_info.lr1mac->rp, &rp_task_cad, info->buffer, 255, &rx_param ) == RP_HOOK_STATUS_OK )
{
    info->state = CAD_STATE_WAIT_CAD_COMPLETION;
}
else
{
    SMTC_MODEM_HAL_PANIC( "RP is busy, fail in config_enqueue_next_cad\n" );
}

I reported two examples but there are many in my opinion.

By the way, I would like to know which is the criteria, just to be sure that the reboots are necessary, because the situations cannot be recovered in any other ways.

Thank you, regards, Laura Scalzo

[lbm-team]

Hi, Thank you very much for your feedback. Do you observe a call to SMTC_MODEM_HAL_PANIC() during the execution of your code ? If so, please copy/paste your error message. Many thanks, Best regards,

[sca-l]

Hi,

the case mentioned in the previous comment is related to an expired task and in running state. I found the root cause of the expiration of task, by the way, in my understanding, an expired task situation could be recovered in a different way without reboot the device. Are you agree? This is the reason of my ticket. I think that some of these situations could be managed in different way without reboot the device.

Regards, Laura

[brianwyld]

Hi, porting this code on an nrf52, I find that the use of the panic macros in the initialisation code (smtc_modem_init()) is not great, as my application code prefers to report any hardware errors (eg missing radio board!) to the user rather than just panic....

I would suggest that this function should return a bool to let the app code know if the init was ok or not, and use the status returns from ral_reset() etc to return false if an error is encountered (I have modified my copy in this way to let my integration be more user friendly...)