[Zigbee] Problem with debugging in Zigbee Thread SDK 4.2.0

[Tu Hoang]

Hi everyone,

So I have using Zigbee and Thread SDK 4.2.0 for a while and I notice that some time there are some error like this

 <error> app: ZBOSS assertion in file: 105, line: 1101

or

 <error> app: ZBOSS assertion in file: 23, line: 105

Well, I tried to look for the error message "ZBOSS assertion in file:" to find clue on how to navigate to the file in zboss to debug. But I can not find any thing use full. So my question is how can I know what the number of each ZBOSS file. 

Please help and thank you,

Tu

[Edvin]

Hello,

I thought these were coming from the ZB_TRACE_FILE_ID in the zboss files, but it looks like that is not the case, unless you have added some files that weren't part of the SDK. Do you have any files that say

#define ZB_TRACE_FILE_ID 23 or 105?

I see that I am having trouble manually asserting in the first place. Can you try to set a breakpoint on line 151 in zb_nrf52_common.c, and check the call stack when the assert occurs?

Best regards,

Edvin

[Jean-Philippe D]

Hello,
I have the same assert:
ZBOSS assertion in file: 23, line: 105

Is it possible to have some information about this, like some code lines and the condition which raise this assert ?

Best regards,
Jean-Philippe

[Tu Hoang]

Well the problem only occur when I send a lot of report attribute to the coordinator (about 1 message/sec) and it will take some time for the problem to happen. The more devices I have (in my case 100) , the faster it happen (approximately in the first 100 times). 

Edvin said:

t possible for me to reproduce your assert on a DK without any external HW

No, unfortunately,  I have another Wifi SoC as a gateway for the coordinator. The NRF52833 and this SoC connected through UART at 1Mbps. A message from UART will initiate an on/off command at the coordinator to the devices and then the device will report attribute back to the coordinator to be transfer back to the Wifi SoC. The code is confidential so I can not upload it to you. 

Best regards,

HNT

[Edvin]

Did you try to replicate the issue by replacing the Wifi SoC with a timer interrupt or something to trigger the events. Does the issue still occur then?

[Edvin]

Perhaps I wasn't clear. The reason to do so is to make a strip down version of the project that:

1: can replicate the issue.

2: doesn't contain confidential data, so it is possible to send.

Another thing that I thought of. Make sure that you don't use zb_buf_get_out_delayed_func() from your custom parts of the application. Make sure that you use only the zb_buf_get_out_delayed() wrapper.

BR,
Edvin

[Jean-Philippe D]

Hello,

I have resolve my problem about this assert (and many other)

An IRQ about UART is occur and the treatment in this case is very long and do local attribut modification, try to send report and other things.

I have move all the possible treatment which not need to be process at the moment in a function, to reduce to the minimum the handler treatment in the case of the IRQ, this is push to the 'APP_SCHEDULER'

Since, no more ASSERT occur, and many spurious behaviour have also disappear.


Best regards,
Jean-Philippe

[Tu Hoang]

Glad to hear that it is resolved for you

The same thing happen with me too . But in my case, I still get problem when put it in app scheduler so I put it in zboss scheduler and the problem is also solve.

BR

HNT