Data reception stops at Mac_802_15_4_FFD in the sample code.

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.

Thank you very much.

I will confirm it immediately.

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.

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.

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.

​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?

​OK thanks

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

Hello

Thank you.

I don't have time to check the RFD due to the ongoing project, but I will check it when I have time.

I also confirmed the phenomenon that the ACK response is not received even when sending. I also contacted the community about this. I'd like to resolve this phenomenon as soon as possible, so I'm sorry, could you please give me an answer?

Title : When the data of IEEE802.15.4 is transmitted by STM32WB55, ACK is returned from the communication partner, but STM32WB55 does not recognize ACK.