About timing in mesh processing

Question

Hello team, I'm working on system development using Mesh SDK and I have some questions so please let me know. ############### Development environment IDE : Segger Embedded Stuido SoC : nRF52840 SDK : Mesh v2.2.0 normal SDK v15.0.0 Base project : light switch example (modifying for our system) ############### 1. If a node belonging to a group receives a message for that group address, which of the following will be performed first? ・Processing for messages, such as replies ・Transfer message to another node ・Anything else. 2. There is possiblity to rewrite the same variable in the receive callback of Mesh message and the timer interrupt handler, in main.c. As such, I do not want to generate other interrupts during this process, includes receiving mesh messages. How can I realize this? Are the following functions and macros useful? ・CRITICAL_REGION_ENTER () / CRITICAL_REGION_EXIT () ・nrf_mesh_disable () / nrf_mesh_enable () 3. About interrupt As far as the document is referred to, when the Mesh message is received during execution of the application interrupt process, the application interrupt is interrupted and the Mesh reception interrupt is processed. I think that system will return to the interrupted application interrupt after the processing of the reception interrupt is finished. Is this recognition correct? I will assume that it is correct and ask a question. Is there a way to see this series of processes? I put a loop processing with an end condition to make the waiting time in the timer interrupt handler. I tried sending Mesh messages during looping, but the timer interrupt handler was not interrupted by the receipt of Mesh messages. On the contrary, mesh message reception interrupt did not occur even after loop termination. Does that mean that the system has not received a message? Or did the system receive it but did not put the interrupt on hold? The code in the timer interrupt handler is described below for reference. void timer_handler(void * p_context)
{
 __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "%s called.
", __func__);
 
 for (uint8_t i = 100; i > 0; i--)
 {
 printf("loop %d
", i);
 }
} Thanks in advance. Wataru

ovrebekk · Accepted Answer

Hi Wataru 
 1. First the packet will be decrypted. Then there will be a check to see if it should be relayed, after which the TTL will be decremented, the packet encrypted again, and put in the outgoing packet buffer. 
 After that the packet will be processed locally. 
 Still, depending on the state of the outgoing buffer there might be some delay before the packet is retransmitted, so whether or not this happens before the local processing is impossible to say. 
 2. An interrupt of the same priority as another can not interrupt it. This also means that an interrupt can not interrupt itself. 
 The only thing that can interrupt you when you are in an interrupt handler is another interrupt of higher priority (lower IRQ priority number). 
 If the timer interrupt has a higher interrupt priority than the mesh interrupt then I would suggest disabling this particular interrupt before you access the shared variable. 
 3. If an application interrupt of lower priority is interrupted by the mesh interrupt, then execution will return to the application interrupt after the mesh interrupt is completed, that is correct. An interrupt of similar priority will not be interrupted. 
 You could visualize this by using a debugger with trace functionality, such as the Segger J-Trace . 
 Regarding your timer_handler, I expect that this is running at an interrupt priority similar or higher than that of the mesh interrupts, which means you are blocking the mesh operation while sending your messages. This is not recommended, as the mesh will not be able to operate as normal. 
 Maybe you could try to defer the execution to the main context instead, either by using the app_scheduler module, or by setting a flag in the timer_handler that you later check in your main loop? 
 Best regards Torbjørn

About timing in mesh processing

Top Replies