2019-07-04 07:22 AM
Hi everyone,
I'm currently working on a STM32WB dongle with an OpenThread MTD co-processor: I've started by modifing the example Thread_SED_Coap_Multicast from package STM32Cube_FW_WB_V1.1.1.
I can correctly going in full low power mode (CFG_FULL_LOW_POWER=1) and the power consumption is awesome!
Anyway, when I try to get more info about the current network from the OpenThread stack it often returns null pointer (for example when I use otIp6GetUnicastAddresses, otIp6GetMulticastAddresses, otThreadGetLinkLocalIp6Address, and many others functions)
Considering that I receive the notifichation from the otSetStateChangedCallback callback and check the role with otThreadGetDeviceRole, I'm sure I'm in the network (and I can both send and receive coap and udp unicast and multicast messages).
I also tried by reading the OpenThread CLI source code and by implementing my code using the CLI as a guideline but where the CLI succeeds, I keep failing...
At this point: are that function implemented? Am I missing something?
Thank you all for the support
Have a nice day
Paul
Solved! Go to Solution.
2020-02-11 02:33 AM
We identified the issue and it will be corrected in the next CubeWB FW package V1.5.0 that is expected to be released next week.
2019-08-22 08:11 AM
Did it happen only in low power mode?
If not it could result from a wrong access to a secure part of the RAM.
2019-08-26 12:06 AM
Hi,
thank you for you reply, it did happen also with low power mode disable, both with FTD and MTD wireless co-processors.
FYI many others ot* APIs works very well... Could anyway be a wrong RAM access? Since the pointers are a direct result from the APIs (they are not part of their input), how can i fix this?
Thank you in advance
Paul
2019-12-11 08:46 AM
Hi,
I've updated to STM32Cube_FW_WB_V1.3.0, updated my nucleo to the last coprocessor fw (MTD) and changed the P-NUCLEO-WB55.Nucleo_Thread_SED_Coap_FreeRTOS example to send the address obtained from otLinkGetExtendedAddress() but i still receive a null pointer (const otExtAddress*) as a result both in debug and sent as a coap message.
I correctly receive the PUT non-confirmable coap message both on a linux board with NCP and on a nucleo with router role.
Please does anyone know how to solve this issue?
Thank you all
Paul
2020-02-09 03:14 PM
Hello,
I have also been experiencing this issue for a while and never resolved. I've attempt to call:
With all the above pointing to empty memory locations. I first reported the issue here: https://community.st.com/s/question/0D50X0000BSanbBSQR/how-to-get-mesh-local-eid-openthread
2020-02-11 02:33 AM
We identified the issue and it will be corrected in the next CubeWB FW package V1.5.0 that is expected to be released next week.