segger embedded studio data breakpoints expressions nRF52833

[Learner]

Hello,

I am trying to set a data breakpoint expression on a global array or global variable  but I don't seem to be able to.

Each time I set a data breakpoint I get a '?' next to the breakpoint. See attached picture.

uint8_t ble_ad[HB_BLE_AD_BUFF_SIZE_MAX].

I am using segger Embedded Studio v5.60 and nRF52833 SoC.

Thank you.

Kind regards

Mohamed

[Vidar Berg]

Hello Mohamed,

I created a global array named 'ble_ad' to try and reproduce this here, but it seemed to work for me. In your case, when you start typing your expression, does the variable get displayed up in the suggestion list as shown here:

?

Kind regards,

Vidar

[Learner]

Hi Vidar,

Thank you for the quick response.

What you did worked for me too. I ran into problems when I tried to use a data breakpoint expression applied to that variable. I suggest you edit your data breakpoint and try to use the expression I am using ble_ad[4] != 0 or any other C-like expression.

After restarting SES IDE I can now set the data breakpoint expression without getting the '?' next to it. Very odd!

However, the program is not breaking as expected. I checked this by setting a breakpoint at the line where ble_ad[6] is assigned the value 0x19 and it does execute this line an breaks.

ble_ad[6] = LINK_LINE_TYPE_HOMEBEACON;

Note, is an enum, defined ia header file as

typedef enum eLinkLineType
{
    LINK_LINE_TYPE_AGENCY = 0x00, /**< ? */
    LINK_LINE_TYPE_BUILDING_OWN = 0x01, /**< ? */

    ...
    LINK_LINE_TYPE_HOMEBEACON               = 0x19U,

    ...

} link_PacketType_t;

Thank you.

Kind regards

Mohamed

[Vidar Berg]

Hi Mohamed,

The map file did not get uploaded. Anyway, the easiest way to try to rule out a stack overflow is often to try increasing the stack size, or have you tried that already? The sysworkq stack can be adjusted through the CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE symbol.

Kind regards,

Vidar

[Learner]

Good Morning Vidar,

Vidar Berg said:

The map file did not get uploaded.

Here it is again.

/cfs-file/__key/communityserver-discussions-components-files/4/1106.zephyr.map

Vidar Berg said:

Anyway, the easiest way to try to rule out a stack overflow is often to try increasing the stack size, or have you tried that already?

Did you have a look at the stack analyzer log file stack_analyzer_logs.txt I attached as a link in my previous message? there is nothing in the logs that suggest the stack is overflowing. Please have a look.

Kind regards

Mohamed

[Vidar Berg]

Hi Mohamed,

The system workqueue stack is here:

.noinit."WEST_TOPDIR/zephyr/kernel/system_work_q.c".0
0x2000d760 0x820 zephyr/kernel/libkernel.a(system_work_q.c.obj)

Learner said:

Did you have a look at the stack analyzer log file stack_analyzer_logs.txt I attached as a link in my previous message? there is nothing in the logs that suggest the stack is overflowing. Please have a

I did, and I am not saying a believe it is a stack overflow. My suggestion was in response to your comment here: 

Learner said:

There is no mention of stack overflow violation but I am suspecting there is.

Kind regards,

Vidar

[Learner]

Good Morning Vidar,

The root cause of the MPU FAULT I was getting is an index that went astray and caused a buffer overflow. I would have thought the tools would have reported a BUFFER OVERFLOW error instead.

So, although I managed to find the bug in my firmware I am still interested in your answer to my previous question,

Learner said:

please help me find where the stack starts and whether it builds up or down.

I would appreciate it if you could answer it or point me to a document that describes this.

Thank you for your support over the last 10 days or so.

Kind regards

Mohamed

[Vidar Berg]

Hi Mohamed,

It is good to hear that you were able to find out what triggered the fault in the end. 

Learner said:

I would have thought the tools would have reported a BUFFER OVERFLOW error instead.

I am not sure how a fault handler could be made to detect buffer overruns. There are not any mechanisms to catch buffer overruns before memory corruption occurs either. The first step which I normally take in these situations is to have a look at the stack trace to see if I can determine where the exception was raised. The "Faulting instruction address" indicated that you may have had a corrupt function pointer. 

Learner said:

I would appreciate it if you could answer it or point me to a document that describes this.

I am not aware of any documentation that covers this, but I showed you where you could find the stack areas in the .map file.

Kind regards,

Vidar