About timing in mesh processing

RE: About timing in mesh processing

ovrebekk — Fri, 21 Jun 2019 12:11:12 GMT

No problem, happy to help 🙂

RE: About timing in mesh processing

wataru_m — Thu, 20 Jun 2019 07:23:58 GMT

Hi Torbjørn

Thank you for your advice.
Actually, I thought the same thing after asking a question.
When I checked on the device now, I could see that the value was set in the INTENSET register immediately after the TWI communication.

Now I know where to look for information about interrupts, thank you.

Best regards
Wataru

RE: About timing in mesh processing

ovrebekk — Tue, 18 Jun 2019 06:50:53 GMT

Hi Wataru

If you look at the driver implementation in nrf_drv_twi.c you will see that interrupts are not enabled until you start a TWI transfer, so after init the INTEN register will still be 0.

You can search for the nrf_twi_int_enable function in nrf_drv_twi.c to see where INTENSET is written.

Best regards
Torbjørn

RE: About timing in mesh processing

wataru_m — Mon, 17 Jun 2019 12:11:54 GMT

Hi, Torbjørn

I learned how to get information about interrupts. Thank you very much.

/**
 * @brief UART initialization.
 */
void twi_init (void)
{
    ret_code_t err_code;

    const nrf_drv_twi_config_t twi_tof_config = {
//       .scl                = 3,
//       .sda                = 2,
       .scl                = ARDUINO_SCL_PIN,
       .sda                = ARDUINO_SDA_PIN,
       .frequency          = NRF_DRV_TWI_FREQ_400K,
       .interrupt_priority = APP_IRQ_PRIORITY_HIGH,
       .clear_bus_init     = false
    };

    err_code = nrf_drv_twi_init(&m_twi, &twi_tof_config, twi_handler, NULL);
    APP_ERROR_CHECK(err_code);

    nrf_drv_twi_enable(&m_twi);
}

I initialize and enable TWI in this way.
I think this is the same as the peripheral example. not right?

Best regards,
Wataru

RE: About timing in mesh processing

ovrebekk — Mon, 17 Jun 2019 11:56:24 GMT

Hi Wataru

You are correct, the INTEN register can not be accessed directly, only indirectly through the INTENSET and INTENCLR registers.

To read INTEN you just need to read INTENSET or INTENCLR, they will return the same thing.

To write to INTEN you have to either set or clear bits independently by writing to INTENSET/INTENCLR.

How do you enable TWI in your example?

Do you use one of the standard drivers?

Best regards
Torbjørn

RE: About timing in mesh processing

wataru_m — Fri, 14 Jun 2019 02:11:44 GMT

Hi, Torbjørn

Thank you for your reply.
I feel that knowledge about Nordic products is being accumulated little by little. :)

I prepared a debugging environment to check the register information a little.
It seems there are peripherals that can and cannot be referenced the INTEN register directory from SDK.
Is this right?

I referenced the NRF_TWI0-> ENABLE and NRF_TWI0-> INTENSET register for TWI.
Before enabling TWI, both registers were "0", and after enabling TWI, ENABLE was "6" and INTENSET was "0".

The TWI interrupt (NACK event) is generated intentionally, but looking at the register, I do not think that the interrupt is enabled.

Is something wrong with the operation or understanding?

Best regards
Wataru

RE: About timing in mesh processing

ovrebekk — Thu, 13 Jun 2019 07:10:10 GMT

Hi Wataru

Your understanding is mostly correct, just a small clarification on INTENSET and INTENCLR:

Both INTENSET and INTENCLR is used to access the internal INTEN register, which is the register that actually enables interrupts.

INTENSET allows you to set bits in INTEN, while INTENCLR allows you to clear them.

Reading either INTENSET or INTECLR will return the same thing, namely the state of INTEN.
It is only when you write to these registers that they behave differently.

Best regards
Torbjørn

RE: About timing in mesh processing

wataru_m — Wed, 12 Jun 2019 09:17:47 GMT

Hi, Torbjørn

Sorry for my late reply.

I understood the peripheral ID information to some extent.
・Is interrupt pending: ISPR register of NVIC
・Whether interrupts are enabled: INTENSET of peripheral register
・Whether interrupts are disabled: INTENCLR in peripheral register

Above is my recognition that where should be confirmed about interruption. Correct?

Best regards
Wataru

RE: About timing in mesh processing

ovrebekk — Thu, 06 Jun 2019 11:12:09 GMT

Hi Wataru

How to calculate the peripheral ID is documented here.

As you can see it is based on the base address of each peripheral, which is documented at the top of the "registers" section for each of the peripherals in the nRF52840 (like here for the SPIM modules).

If all the application interrupts are executed at the same priority it means they will all have to wait for each other. One will not be able to interrupt another.

"In this case, high priority interrupts are considered to be time critical processes closer to the physical layer, are they correct?"

Yes, this is correct. Normally the timing is more critical the closer you get to the physical layer, and it is the same for Bluetooth mesh.

Best regards
Torbjørn

RE: About timing in mesh processing

wataru_m — Wed, 05 Jun 2019 11:46:37 GMT

Hi Torbjørn

I see. If I need to measure the time it takes to process the interrupt, I follow your idea.

I did not refer to any register yet.
I was just looking for information on where to look.
I searched for the specification of nrf52840, but I did not know which NVIC register should I actually watch .
In addition, information on peripheral device ID was not found as well. . .

There is no reset or system OFF status. Even the application does not access the RTC register. (Other than timer)
At the application level, all interrupt processes are executed with the same priority (7).

In this case, high priority interrupts are considered to be time critical processes closer to the physical layer, are they correct?

Best regards,
Wataru

RE: About timing in mesh processing

ovrebekk — Wed, 05 Jun 2019 11:17:29 GMT

Hi Wataru

Yes, my proposal is to set a pin at the start of the interrupt handler, and clear the pin at the end of the interrupt handler. Then you can see accurately when the interrupt handler starts, and for how long it runs.

I am not quite sure what register you are referring to. You should be able to read the pending state of the various interrupts from the ISPR registers in the NVIC peripheral, where each bit stores the pending state of one peripheral.

ISPR[0] covers peripheral ID's 0-31, ISPR[1] covers ID's 32-63, and so forth.

As for the RTC stopping this won't happen unless you do a system reset, enter system OFF sleep mode, or disable the low frequency clock source from the application. You could also manually stop the RTC from the code, but there is no reason the mesh stack should do this, and I assume you don't access the RTC registers either in the application code?

In other words I don't see how the timer interrupt generation could be affected, but the execution of the timer handler interrupt could be delayed if a higher priority interrupt is currently running.

Best regards
Torbjørn

RE: About timing in mesh processing

wataru_m — Mon, 03 Jun 2019 13:17:17 GMT

Hi Torbjørn

It is possible to connect to an oscilloscope.
Are you saying to toggle any GPIO when an interrupt occurs?
If possible, I would like to check the register of each interrupt directly. . .
Is it impossible to make it with logs?

I think that the some delay may be tolerance to knowing the status of the interrupt register in software..
By the way, can you give us information about which register to look at? I would to know this information at least.

BTW, as I mentioned earlier that no timer interrupt has occurred, is the possibility of my misunderstanding.
I was doing each processing in a fixed cycle, but rearly, I had not had an event that should have happened on a rare cycle so I judged.

But, The time stamp output from the LOG in the timer interrupt handler proved that it was operating at the intended interval.

Is there a possibility that this information (timestamp) is unbelievable?
If so, I think that means that RTC sometimes stops.

It has not yet been confirmed that the operation cycle of one timer in the system was correct.
But I have a question.
Does it happen occasionally that the timer interrupt generation cycle deviates from the intended one?

Best regards,
Wataru

RE: About timing in mesh processing

ovrebekk — Mon, 03 Jun 2019 12:30:43 GMT

Hi Wataru

Are you able to connect your kit to an oscilloscope?

Then you can toggle a pin at the start and end of the interrupt vector, and use the oscilloscope to monitor when the interrupt triggers, and how long it runs.

While a bit primitive, this is a very non intrusive and reliable way to measure the interrupt activity. Writing to the log can be quite slow, and might not be able to keep up with the interrupt activity.

Best regards
Torbjørn

RE: About timing in mesh processing

wataru_m — Fri, 31 May 2019 11:58:57 GMT

HI, Torbjørn

I'm sorry for my late reply.

I understand that the interrupt vector only has a status of pending or not.
By the way, can the status of the interrupt vector be checked by outputting it in LOG during processing?
In the systems we operate, it has been found that, very rarely, timer interrupts do not occur at the expected time.
In order to prove this, I want to know the state of the vector table and so on.
Alternatively, please let me know at the same time if there are other registers useful for debugging.

Yes, It is a physical transfer by radio.
There seems to be no problem with message hoping.
I do not intend to process the contents of the relay message payload.

I also understood the priority of mesh processing in the main application.
I was a little surprised at the lowest priority, but it does not interfere with the time critical processing of lower layers.

Best regards
Wataru

RE: About timing in mesh processing

ovrebekk — Wed, 22 May 2019 10:08:23 GMT

Hi Wataru

Each interrupt vector is either pending or not pending, it doesn't track how many times the interrupt occurs. If you suspect that the interrupt could happen multiple times before you have time to process the first one you will have to check at the end of the interrupt if there is any more data to process before leaving the interrupt.

Typically this would be implemented by pushing the relevant event data into a FIFO buffer before setting the interrupt pending. Then you can check the state of the FIFO buffer at the end of the interrupt handler, and if the interrupt happens multiple times before you are able to process it you will have to run through all the items in the FIFO.

When using this approach the number of interrupts you can 'hold' is set by the size of the FIFO (how many elements can the FIFO hold).

"Where is message transfer actually done? "

You mean the physical message transfer over the air?

This is handled by the lower layers of the mesh implementation, which is included for you by the light_switch example. The application should not have to worry about this, as long as you don't try to push more data through the mesh than it can handle.

"In other words, at the higher level, like the application layer, is it that the processing priority for messages is set to the lowest value (7)? Like below."

Interrupts for the application are running at the lowest priority, yes, which means they might be delayed by higher priority interrupts in the lower parts of the mesh stack. This is done to make sure that the processing of mesh events in the application will not affect or delay the time critical mesh operations happening in the stack.

Best regards
Torbjørn

RE: About timing in mesh processing

wataru_m — Tue, 21 May 2019 05:29:34 GMT

HI, Torbjørn

Thank you for the reply, I feel that the problem I'm concerned about is gradually solved.

It turns out that the pending interrupt never disappears.
So how many interrupts can I hold?
Is that something defined elsewhere? Can I change it?

Here is a concrete example.
When sending messages from five to six edge devices to one gateway device at the same time (as a reply to the message from the gateway), can the gateway receive all messages at once?

I'm not clear in me if there is a direct relationship with the interrupt ,,,
Where is message transfer actually done? That functionality is included in the light_switch sample project, right?
Does a developer need to develop an application that he wants to realize while also being concerned with message transfer processing (timing etc.)? Or is the message transfer process independent of the application, and the developer does not need to worry? Which one?

" I wouldn't say less important, just less time critical. In most communications protocols the lower levels of the protocol, closer to the physical layer, are more time critical. The higher levels, closer to the application, don't have to be processed right away, but can be processed whenever the CPU has some free time. "

In other words, at the higher level, like the application layer, is it that the processing priority for messages is set to the lowest value (7)? Like below.

static void mesh_init(void)
{
    uint8_t dev_uuid[NRF_MESH_UUID_SIZE];
    uint8_t node_uuid_prefix[NODE_UUID_PREFIX_LEN] = SERVER_NODE_UUID_PREFIX;

    ERROR_CHECK(mesh_app_uuid_gen(dev_uuid, node_uuid_prefix, NODE_UUID_PREFIX_LEN));
    mesh_stack_init_params_t init_params =
    {
        .core.irq_priority       = NRF_MESH_IRQ_PRIORITY_LOWEST,
        .core.lfclksrc           = DEV_BOARD_LF_CLK_CFG,
        .core.p_uuid             = dev_uuid,
        .models.models_init_cb   = models_init_cb,
        .models.config_server_cb = config_server_evt_cb
    };
    ERROR_CHECK(mesh_stack_init(&init_params, &m_device_provisioned));
}

Thank you for providing a simple example of how to use app_scheduler.
First of all, we will study the specifications while doing a simple experiment to update the system.

Best regards
Wataru

RE: About timing in mesh processing

ovrebekk — Mon, 20 May 2019 13:25:47 GMT

Hi Wataru

"If for some reason it takes a long time to process the current interrupt,
can you say the same thing?"

The pending interrupts won't be forgotten or timed out, if that is what you mean, but if you have very long interrupts in your system it could affect the performance of the mesh.

In general I would say it is not recommended to have interrupts lasting for much more than 10-50 milliseconds.

"Do you say that in the light_switch example, the callback function (eg, get / set) in main.c is a less important mesh operation?"

I wouldn't say less important, just less time critical. In most communications protocols the lower levels of the protocol, closer to the physical layer, are more time critical. The higher levels, closer to the application, don't have to be processed right away, but can be processed whenever the CPU has some free time.

"By the way, if you try to port from the method of executing each operation by the interrupt like the sample to the method of using app_scheduler, is it so difficult?"

No, I think using the app scheduler is quite simple. All you have to do is to put the code that you want to schedule into a function, which needs to have the function signature like this:

void my_app_sched_event_handler_1(void *p_event_data, uint16_t event_size)
{
// Your code here...
}

Then you use the app_sched_event_put() function to schedule this function to be run, and any data that you provide in the p_event_data and event_size variables will be available to the function once it is run.

Best regards
Torbjørn

RE: About timing in mesh processing

wataru_m — Mon, 13 May 2019 11:40:10 GMT

HI, Torbjørn

Thank you. I was able to spend a nice day off.

I felt relieved to hear that both the processing for the message
and the forwarding of the message are performed.

I understood that if an interrupt occurs while processing the same priority, it will be suspended.
If for some reason it takes a long time to process the current interrupt,
can you say the same thing? (Does the pending interrupt be executed after the processing ends?)

Do you say that in the light_switch example, the callback function (eg, get / set) in main.c is a less important mesh operation?
If so, there is a slight strange. . .

Thank you, I will refer to the document about app_scheduler.
By the way, if you try to port from the method of executing each operation by the interrupt like the sample to the method of using app_scheduler, is it so difficult?

Best regards
Wataru

RE: About timing in mesh processing

ovrebekk — Fri, 10 May 2019 09:07:59 GMT

Hi Wataru

I hope you had a good vacation 🙂

1. Yes, you can't tell for sure if the messages will be relayed or processed first, but both processes will be performed eventually.

2. Yes. If you are in an interrupt, and another interrupt at the same priority occurs, the second interrupt will be executed after the first interrupt is completed. An interrupt can only be interrupted by another interrupt that has a higher priority (lower priority number).

The mesh interrupts are explained in more detail here.

Essentially the time critical radio interrupts are running at priority 0, which is the highest priority in the system. This ensures that during critical mesh processing the stack will not be interrupted by anything else.

Less critical mesh operations run at a lower interrupt priority (higher number), and can even run from the main context, so these interrupts you should be able to block for a while without any ill effects.

The app_scheduler library is documented here.

Best regards
Torbjørn

RE: About timing in mesh processing

wataru_m — Thu, 09 May 2019 09:35:21 GMT

HI, Torbjørn

Thanks for your reply and I'm so sorry for the too late reply.
I took long vacation...

I understood that it was the same as the information described in the map file. .
Thank you very much.

###

"BTW, can you answer another question on this thread?"

Which question would that be?
###

What I commented on your response to my first question.
I quote below.

###

1. My understanding that the order to execute first is not decided, is it correct?
(Processing of messages or relaying of messages)
Even in that case, both processes will be performed?

2. If an interrupt with the same priority occurs while processing in the interrupt handler,
will interrupt processing that occurs later be on hold?
In other words, will interrupt processing that occurs later be executed
after the current interrupt handler has ended?

By the way, in the light_example example, what is the priority of mesh interrupts?
I think the priority is "0". Does that mean not?
The timer interrupt priority is set to LOWEST (7).

Although it is not intended, if you can block mesh interrupts,
do you think that blocking mesh interrupts is not a problem
if it is an algorithm that can collect data in multiple communications?

I don't want to do this now because using the app_scheduler is likely to result in many system changes.
I would like to consider again at the timing of the big update,
so please inform me about how app_scheduler works and how to use it.

###

I think that it is related to my first question, so I do not want to launch a new thread.

I look forward to your answer.

Best regards,
Wataru

RE: About timing in mesh processing

ovrebekk — Wed, 24 Apr 2019 13:30:05 GMT

Hi Wataru

Yes, that is the same information. If you change the settings in SES and recompile you should see the values in the map file change.

"BTW, can you answer another question on this thread?"

Which question would that be?

Edit: If you have a new question not directly related I would suggest opening a new thread. In particular since I don't have a lot of experience with the mesh SDK ;)

Best regards
Torbjørn

RE: About timing in mesh processing

wataru_m — Wed, 24 Apr 2019 00:37:11 GMT

HI, Torbjørn

Thanks for your reply.

Is that the information you gave me is the same as the one described in the map file?
(I attach it below. )

BTW, can you answer another question on this thread?

Best regards
Wataru

RE: About timing in mesh processing

ovrebekk — Tue, 23 Apr 2019 12:05:53 GMT

Hi Wataru

To check the size of your heap and stack you should open the project options in Segger Embedded Studio, select the 'common' configuration, and open the 'Runtime Memory Area' section as shown in the below screenshot:

Best regards
Torbjørn

RE: About timing in mesh processing

wataru_m — Wed, 17 Apr 2019 10:47:14 GMT

Hi,

Please let me ask another question related to it.

In the project I wrote,
How can I check stack memory and heap memory respectively?
I want to know these addresses and sizes.

BR,
Wataru

RE: About timing in mesh processing

wataru_m — Mon, 15 Apr 2019 01:32:08 GMT

Hi, Ovrebekk

Thanks for your reply. And sorry for the late my reply.

1. My understanding that the order to execute first is not decided, is it correct?
(Processing of messages or relaying of messages)
Even in that case, both processes will be performed?

2. If an interrupt with the same priority occurs while processing in the interrupt handler,
will interrupt processing that occurs later be on hold?
In other words, will interrupt processing that occurs later be executed
after the current interrupt handler has ended?

By the way, in the light_example example, what is the priority of mesh interrupts?
I think the priority is "0". Does that mean not?
The timer interrupt priority is set to LOWEST (7).

Although it is not intended, if you can block mesh interrupts,
do you think that blocking mesh interrupts is not a problem
if it is an algorithm that can collect data in multiple communications?

I don't want to do this now because using the app_scheduler is likely to result in many system changes.
I would like to consider again at the timing of the big update,
so please inform me about how app_scheduler works and how to use it.

Best regards
Wataru