SMTC_MODEM_HAL_PANIC macro usage in not critical conditions #115

Activity

1. opeyrard commented on May 20, 2025

   

   opeyrard

   on May 20, 2025

   More actions

   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,
2. sca-l commented on May 20, 2025

   

   sca-l

   on May 20, 2025

   Author

   More actions

   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
3. lbm-team commented on Jul 16, 2025

   

   lbm-team

   on Jul 16, 2025

   Contributor

   More actions

   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,
4. sca-l commented on Jul 18, 2025

   

   sca-l

   on Jul 18, 2025

   Author

   More actions

   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
5. brianwyld commented on Sep 2, 2025

   

   brianwyld

   on Sep 2, 2025

   More actions

   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...)