About the handler of "nRF52832"

[KURODA ELECTRIC]

Hello.

We are developing products using BLE modules.

The one used for that module was "nRF52832 (512kB Flash, 64kB RAM)".

 

I would like to know

Question 1:

As a basic operation, I understand that various handlers are registered in Nordic's SoftDevice and are called back when an event occurs.

Is it necessary to exclusively control this callback on the normal processing side when using a buffer common to our normal processing?

 

Question 2:

If you need exclusivity, what are your options?

 

Question 3:

If another event occurs while processing the event handler, will the event handler that occurred later take precedence?

 

Thank you.

[ovrebekk]

Hi

As a basic operation, I understand that various handlers are registered in Nordic's SoftDevice and are called back when an event occurs.

Correct. There is a system callback for handling system level events, such as flash write complete, and then there is a BLE callback for handling events related to the BLE stack. 

Is it necessary to exclusively control this callback on the normal processing side when using a buffer common to our normal processing?

My apologies, but I am not quite sure what you mean by this question. Can you try to rephrase the question?

Question 3:

If another event occurs while processing the event handler, will the event handler that occurred later take precedence?

Internally in the SoftDevice all events are added to an event queue, and they will be processed one after the other in the order they were generated. 

In other words, if you are busy processing one event while the next one happens, the last event will only be processed after you are done processing the first. 

Because events are processed in an interrupt context it is not recommended to perform very heavy or slow processing inside the event handler. If you need to run a lot of code as a result of a SoftDevice event it is recommended to use a flag or a scheduler to execute the processing in the main context. 

Best regards
Torbjørn 

[KURODA ELECTRIC]

Dear Torbjørn 

Thank you for your reply below.

Regarding Question 3, after the processing of the first event is completed I understand that events that occur later will be processed.

Regarding questions 1 and 2, I am sorry that the question is difficult to understand.

We will change the question as follows.

Questions 1 and 2: Please refer to the attached typical case.

The buffer is shared between main () and the event handler, While manipulating the buffer with main () I don't want the event handler to manipulate the buffer.

In that case, add a function like Mutex in a multithreaded program, or I think it is necessary to temporarily stop the occurrence of the event handler. How should we achieve the above?

---

uint8_t g_pucBuffer1[256];
uint8_t g_pucBuffer2[256];

static void sample_handler(void * p_context);

int main(void)
{

// Initialization process omitted.

while (1)

  {
  // I don't want the handler to rewrite the buffer until the following processing is completed.
  // I think we need an exclusion like Mutex in multithreading.
        memcpy(g_pucBuffer1, g_pucBuffer2, 256);

}
}

void sample_handler(void * p_context)
{
 memset(g_pucBuffer2, 0xAA, 256);

---

Thank you for your cooperation.

[ovrebekk]

Hi 

Thanks for the information, now the question is clear

It is true that if you want to access the same buffer from the main context and from the Bluetooth event handler, you need some way to control this. 

1) Flag method: When the BLE event occurs you should not access the shared buffer directly, but set a flag that you can check in the main loop. Then you can check this flag in the main context and access the shared buffer safely. 

2) An alternative method is to use the sd_nvic_critical_region_enter() and sd_nvic_critical_region_exit() functions whenever you access the shared buffer in the main context. This will ensure that no BLE events are executed within this region. 

I would not recommend this method if the memory access in main takes a long time to execute, but small buffer copy operations should be fine. 

Best regards
Torbjørn

[KURODA ELECTRIC]

Dear Torbjørn 

Thank you for your teaching.

Thank you very much for helping me!

[ovrebekk]

You welcome, I am happy to be of help. 

I wish you the best of luck with your project

Best regards
Torbjørn