access_model_publish_period_set() stopped working when migrating to Mesh SDK 4.2.0

[EAn]

Greetings,

I am currently using nRF5 SDK 16.0.0, Softdevice s140_nrf52_7.0.1_softdevice.hex, and Mesh SDK 4.2.0. I migrated all my code base from  nRF5 SDK 15.3.0, Softdevice s140_nrf52_6.1.1_softdevice.hex, and Mesh SDK 3.2.0. 

I have a Bluetooth mesh device which I hard-coded the publication address and period after initializing. This has always worked just fine, but after switching to the newest SDKs I got a mesh assert in the access_model_publish_period_set... If I comment that line everything works fine and I can setup the publication via the nRF Mesh App.

Could you point me in the direction of what I should be looking at? I've tried backtracking and debugging the error and I was able to trace it all the way back to "void bearer_event_flag_set(bearer_event_flag_t flag)" in /nrf5_SDK_for_Mesh_v4.2.0_src/mesh/core/src/bearer_event.c ... but didn't get any inkling as to what is generating the issue...

I found a workaround where I use a normal timer (app_timer type) and call the publication cb from there... It's not the most elegant solution but works for now, as for the time being we are hardcoding the publication setup in our devices....

Could you please give me some pointers/solutions? Thank you very much!

Best regards!

//EA

[tesc]

Hi,

You did not mention the exact location of the assert (was it an unexpected error return value from an API call or underlying function, and if so which one?) How did you trace it to "void bearer_event_flag_set(bearer_event_flag_t flag)", is it inside of that function that it asserts (if so where?)

I assume that you have already followed the migration guide, although I did not find anything striking there.

Figuring out exactly where it fails (and with what error return value, if any) would be the best step going forward.

Regards,
Terje

[EAn]

Hi Terje,

Tusen takk for your reply!

Yes, I followed the migration guide.

I did get an "app_error_weak.c,  105, Mesh assert at 0x0003CD82 (:0)"

Which I tried to pinpoint using:
addr2line -paf -e  <ProjectName>.elf  0x0003CD82

Which gave:

0x0003cd82: backend_entry_evt_handler at .../nrf5_SDK_for_Mesh_v4.2.0_src/mesh/core/src/mesh_config.c:402

I pinpointed the location by using successsive breakpoint and diving into the functions where the assert resulted, going deeper and deeper into the rabit hole untill I got stuck there in the "void bearer_event_flag_set(bearer_event_flag_t flag)" in /nrf5_SDK_for_Mesh_v4.2.0_src/mesh/core/src/bearer_event.c "

I'm using an APP_TIMER to work around that issue.

I was migrating the firmware of another device of our ecosystem to the new sets of SDKs and it also breaks in access_model_publish_period_set(), but this time I found out that if I set the uint8_t step_number (last var in the function call) to "0" it runs just fine .... I manually set the value to (uint8_t) 5000, and it gave me again a

app_error_weak.c,  105, Mesh assert at 0x00033EA2 (:0)

which by using "addr2line -paf -e <ProjectName2>.elf 0x00033EA2" resolves to:
0x00033ea2: hardcodePublicationSettings at /ProjectSRC/InterfaceMesh/main_mesh.c:2512 (discriminator 1)

Where I basically have " NRF_MESH_ASSERT(access_model_publish_period_set(model_handle, publish_resolution, (uint8_t) 5000 ) == NRF_SUCCESS);"

EDIT:

edit/
I proceeded to comment that line, recompile, run, re-provision and once again I get "app_error_weak.c,  105, Mesh assert at 0x0003D746 (:0)"
Running addr2line there gave:

0x0003d746: backend_entry_evt_handler at ...nrf5_SDK_for_Mesh_v4.2.0_src/mesh/core/src/mesh_config.c:395
However that line belongs to "bool mesh_config_entry_available_id(mesh_config_entry_id_t * p_base_id)" .

Is there any way to use conditional breakpoints when there is a function that only gives a mesh_assert after a certain line of code is passed?

/end edit

Regards,

EA

[tesc]

Hi,

I am very sorry for the delay.

According to the documentation for access_model_publish_period_set(), the max value of step_number is 0x3F. A value of 5000 is much higher than what can be stored in an uint8_t, which has a range of 0 to 255 inclusive. The result of assigning a value that do not fit may depend on compiler, but in most cases I would expect the value to be cropped, so that 5000 (decimal) becomes 0x1388 hexadecimal, cropped to one byte it becomes 0x88 (only the last byte) which is larger than 0x3F.

You can figure out the return value from the call to access_model_publish_period_set() for instance by assigning the return value to a separate variable, before doing NRF_MESH_ERROR_CHECK() on that value. Then you should have the value on the stack when you assert, so that you can check it. (Although in this situation we can be pretty certain the return value is NRF_ERROR_INVALID_PARAM, which for this function means "Publish step and/or resolution out of range.")

Regards,
Terje

[EAn]

Hi there,

I just wanted to do a quick report. What solved my issue was basically calling the hardcode publication and subscription routine from a delayed one-shot timer (using app_timer). It seems that it was all a priority issue... Funny huh?
I still is frustrating that it took me that long amount of time to find a solution, and that there was no clue to that that I could find in the forum or documentation... I just experimented with different timings. First calling the routine from an RTT interrupt...

Regards

//EA

[tesc]

Hi,

It sounds a bit strange that it stopped working after migration, but if priorities were involved then there might have been a timing change (either deliberate or arbitrary due to minor code changes.)

Do you by any chance have priority settings not in alignment with what is described on the Setting interrupt priority levels documentation page?

Regards,
Terje

[EAn]

Thanks for your pointer. The issue was solved somehow. Your reply made us more aware of the timing and priority issues that may emerge with the mesh SDK. Thanks Tesc!