Appkey always equals 0 in my custom model in BT mesh

[lalum]

Hello everyone,

I'm currently trying to create Bluetooth mesh custom client and server with the nrf connect sdk. 

The purpose of my application is to make my server send data automatically to my client when it receives a particular message from it.

A very common type of communication between a server and a client !

To send a message to my server, my client use the model publication context configurated by the Configuration Client Model. (so I use publish function)
To send a message to my client, my server use the publication context of my client request to respond to the client. (So I use send function)

My problem is that my server failed to respond to my client because the Appkey that it receives from my client always equals zero, and it doesn't recognize it. I have this error :

"E : Model don't bound to AppKey 0x000"

After this error, my server is no longer able to receive messages from my client.

I use the phone app nrf mesh to provision my node and to provide an AppKey to my Client and my Server.

If you have any idea about what can cause this problem it would be very helpful !

[AHaug]

Hi,

Could you supply me with some more info about the following: 

1. Can you verify if you are working with nRF Connect SDK and if so what version are you using?
2. Is "E : Model don't bound to AppKey 0x000" the exact error message you are receiving or is it translated to English? 
3. You state you're using the nRF Mesh application to provision your node. Can you state which phone OS you are using (and what version of the mobile application)?
4. Did you base your custom application on any existing samples? If so, could you supply them to me?

Kind regards,
Andreas

[lalum]

Hi,

thanks for your reply ! For a strange reason it works now ... I don't succeed to identify the source of the problem... And I don't really like it because I didn't do something in particular and I'm afraid that the problem will reappear.

So I give you the answers just in case :

1. I work with nRF connect sdk on visual studio code, v1.9.1 release
2. Yes it was the exact error message that I received when I connected my nrf52840 in serial and I started communication

3. I use nrf Mesh 3.2.4 on an Androïd phone
4. I base my custom application on several examples such as the generic OnOff models in the nrf sdk and the chat sample

kind regards

[AHaug]

AHaug said:

The value of ctx->app_idx is indeed equal to 0 in my reception function "bt_mesh_handle_message_request" but once in the thread "My_thread" the value rx_ctx->app_idx is equal to 0x2000... I don't understand why the value of ctx changes without my intervention. I tried to put the ctx value as a global variable and thus not pass ctx as an argument of my thread, but the result is the same, once in the thread rx_ctx->app_idx = 0x2000....

I got a reply with regards to this: 

Rx context is the local variable from here: https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/mesh/net.c#L371-L391 
However, it is not correct to use a pointer to the local variable from the stack of one thread as incoming data for another thread. This might result in some bugs further down in development that is hard to solve. To be sure that you do this properly, I would recommend taking a look at how Zephyr does threading, context switching, stack allocation and make sure you understand it quite thoroughly before doing "tricks" like what you're attempting right now

In addition, topic 7 and 8 in this course is a great entry level overview over multithread applications if that that  topic is new to you, as well as Zephyr's thread documentation, thread API and thread samples

Kind regards,
Andreas

[lalum]

Hi Andreas, thank you so much for your reply and your help !
Indeed, I'm a newbie with multithreading ... so I think the link to the course can help me !

when you talk about my "tricks" you think about the way I recreated the publication context with using the address of the node which has sent the message as the destination address ? This method is not correct ?
Or it was about my first example that didn't work where I was trying to use all the context as my thread argument ?

Kind regards and thanks

[AHaug]

Hi,

lalum said:

when you talk about my "tricks"

I would first like to add that if they work without causing issues down the line, they are completely viable , but in this case what you will most likely face is that when you use a pointer to a local variable frome one thread as incomming data for another thread, you can not guarantee that the variable exists. As an example, the incoming data to some callback will not exist outside the callback context.

I also believe this question might be more sufficiently answered by my colleague in case #293377 (if thats the same application that you're working on there)!

Kind regards,
Andreas

[lalum]

Hi Andreas,

Sorry for the late reply, I need to explore Zephyr and Thread process to better understand my problem !  

Ok I think I understand my problem now ... Thanks to your explanation, it's much clearer. Indeed, if the publication context is a local variable of the thread that receive the message I cannot just use it in an another thread which is responsible for sending message.
So it explains this strange and unreliable behavior !

Thanks a lot for your explanations and your patience

Kind regards

Maureen

[AHaug]

Hi Maureen,

I am glad to hear that our explanation has helped you!

Is it ok if I mark this case as a verified answer? You may always open up new cases and add details from this case to the new one for context!

Kind regards,
Andreas

[lalum]

Hi Andreas,

yes it's ok for me !

thanks !

Maureen