Data reception stops at Mac_802_15_4_FFD in the sample code.

[MNitt.1]

Hello

This is my first time using the community. I don't understand how to use the community

Let me ask you a question.

Currently, I am checking the reception of IEEE802.15.4 on the board of STM32WB55 Nucleo Pack using the sample Mac_802_15_4_FFD.

Stm32wb5x_Mac_802_15_4_fw.bin Ver 1.8 is written to CPU2. 30ms TM_Delay () after the sequence in the main loop

Is put in. Also, in APP_MAC_mcpsDataIndCb (), we only toggle the LED.

In this state, when the transmitting side continuously transmits at intervals of about 500ms, it is received without problems even after about half a day, but when the transmitting side continuously transmits at intervals of 10 to 100ms, it is received after several hours. But

It will stop. This phenomenon will occur no matter how many times you go.

When I checked the details, the IRQ interrupt (IPCC_C1_RX_Handler) from CPU2 did not come in.

If you know why the IRQ interrupt from CPU2 does not come in if the transmission interval is short

Can you tell me? Also, is there a workaround?

[Remi QUINTIN]

I suspect an overload on the M4 core with an issue regarding the re-entrance of the ISR that may have led to a kind of stack overflow, crashing the M4 core.

Could you try the same test with the last CubeWB FW pacakge v1.9.

A few points have been improved on this side with tis v1.9 version.

[MNitt.1]

Thank you very much.

I will confirm it immediately.

[Imen.D]

Hi @MNitt.1​ ,

Could you please confirm if your problem is resolved ?

You can select the post as a "Best Answer" if it solved your problem or answered your question.

Imen

[MNitt.1]

Hello

I don't really understand how to use this community. sorry.

I'm checking the operation with V1.9 that you taught me. As for the situation, when the main loop of the sequencer is operated at 100ms intervals, reception stops in a few hours to half a day. When the main loop was set to operate at 30ms intervals, reception did not stop even after one day. I don't know if it's the Best Answer.

I'm considering various things now, is it possible to update F / W using wireless (BLE/IEE802.15.4) with stm32wb5x_Mac_802_15_4_fw.bin, or I have to use another protocol stack. I'm wondering if it should be evaluated as it is. It is different from the content of this question, but I would appreciate it if you could tell me.

Also, I inquired about the development of a wireless communication F/W that runs on CPU2, but since there was no answer about that, I could not judge whether it could be developed or not, so it is provided as it is in binary. I'm wondering if it's okay to proceed with development with the protocol stack.

[Remi QUINTIN]

No worry. We like having feedback from members in order to provide a better support to the community. This also helps us forward suspect issues to our development teams when we know the problem is not solved despites our support/recommendations.

Regarding your issue, I asked someone from the Thread team about a potential low limit regarding the time interval in between two commands. But I am puzzled by the fact that it works again pretty weel when the connection interval is set to 300ms.

I would like to confirm one point: is the 100ms interval you are mentioning the connection interval, right?

Normally you have to wait for the return of the previous command before sending a new one.

Regarding the other questions:

stm32wb5x_Mac_802_15_4_fw.bin is meant to be use as RF stack with the Nucleo\Applications\Mac_802_15_4\Mac_802_15_4_FFD project.

I thought you were already using this binary with the FFD project.

stm32wb5x_Mac_802_15_4_fw.bin

• MAC API is based on latest official IEEE Std 802.15.4-2011
• To be used for MAC FFD and RFD devices

Regarding the development of a proprietary RF stack on CPU2, this is not possible as we consider CPU2 as a coprocessor dedicated to run the certified ST RF stacks.

Opening the CPU2 to external development would expose us to a lot of support considering all the tight real time constraints involved by the RF aspects.

[MNitt.1]

Hello

The projects I used in my experiments are stm32wb5x_Mac_802_15_4_fw.bin and Nucleo\Applications\Mac_802_15_4\Mac_802_15_4_FFD project. The edited code is as follows.

----- main.c -----

int main(void)

{

 /* Initialize the HAL */

 HAL_Init();

 BSP_LED_Init(LED1);

 BSP_LED_Init(LED2);

 BSP_LED_Init(LED3);

 /* Reset HW IP IPCC/Backup Domain */

 Reset_Device();

 /*Configure the system clock */

 SystemClock_Config();

 /* Configure the system Power Mode */

 SystemPower_Config();

 Init_Debug();

 APP_DBG("**** FFD MAC 802.15.4 EXAMPLE ****");

 /* Application init */

 APP_ENTRY_Init(APPE_FULL);

 /* Main Loop */

 while (1)

 {

   UTIL_SEQ_Run( UTIL_SEQ_DEFAULT );

   HAL_Delay( 100 ) ;

 }

}

----- app_ffd_mac_802_15_4_process.c -----

MAC_Status_t APP_MAC_mcpsDataIndCb( const MAC_dataInd_t * pDataInd )

{

 memcpy(&g_DataInd,pDataInd,sizeof(MAC_dataInd_t));

 BSP_LED_Toggle(LED3);

 return MAC_SUCCESS;

}

It was well understood that the development of RF STACK for CPU2 was not possible. Thank you very much.

[Remi QUINTIN]

​Ok we'll have a look at your changes. Could you make a zip file of you project, just in case we would need to investigate further?

[MNitt.1]

Thank you

I will upload the project.

[Remi QUINTIN]

​OK thanks

Could you also download the RFD SW part to be sure we are in the same conditions.