carlescufi
commented
2 years ago Can you please double all stack sizes and try again? You can find all stacks by looking for _STACK_SIZE in build/zephyr/.config
Closed soerlemans closed 2 years ago
carlescufi
commented
2 years ago Can you please double all stack sizes and try again? You can find all stacks by looking for _STACK_SIZE in build/zephyr/.config
alissa-maria
commented
2 years ago @carlescufi Thank you, this fixed our issue (am also part of the team). Is there a way to define the stack sizes in the prj.conf of a program?
soerlemans
commented
2 years ago After enabling some (KConfig) options for MPU protection. We quickly got the following output after testing again.
[00:00:16.167,000] <err> os: r0/a1: 0x00000002 r1/a2: 0x20000c68 r2/a3: 0xf0f0f0f0
[00:00:16.167,000] <err> os: r3/a4: 0x20001f48 r12/ip: 0x00000003 r14/lr: 0x08006239
[00:00:16.167,000] <err> os: xpsr: 0x41000036
[00:00:16.167,000] <err> os: EXC_RETURN: 0x0
[00:00:16.167,000] <err> os: Faulting instruction address (r15/pc): 0x080136dc
[00:00:16.167,000] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
[00:00:16.167,000] <err> os: Fault during interrupt handlingWe are apparently getting a stack overflow somewhere. What would be the best way to deal with this stack overflow? We use a lot of strings for sending AT commands and those can get quite long. There is no way for us to easily optimize and save more memory.
Is just doubling the stack size an acceptable solution (as we are planning on merging the driver into Zephyr, so correctness matters).
soerlemans
commented
2 years ago We doubled the stack sizes in the prj.conf and accepting this as our solution as it overflows if we do not double the CONFIG_LOG_PROCESS_THREAD then we get a stack overflow.
So its reasonable to double the stack sizes.
Me and my team of students are working on a driver for an Ublox SARA N310. We are planning on merging this driver into Zephyr when the driver is complete.
We currently have a critical issue where a semaphore causes a usage fault deep into Zephyr itself. When we use a response semaphore for the
modem_cmd_send()function it gives a usage fault. We call this function via a wrapper function calledsend_at_command()its does nothing but forward the arguments to themodem_cmd_send()function. Thesend_at_command()function gets used by a number of our public functions defined in drivers header file.The catch is that the function does not fail on the first few calls. It fails after a set amount of calls to the function in rapid succession. The amount can vary when I added a new public function that used
send_at_command()function the problem shifted a few functions down (my guess is that something is going wrong in the stack). On some functions it always fails on the semaphore and gives a usage fault. Sometimes when a function is called twice it will fail. With a usage fault on the second call. Different public functions give different usage faults.The problem does not occur when slowly stepping through the code with a debugger. I included the result of a
thread apply all btin a file for review. The problem happens inmodem_cmd_send_ext()on the second call tok_sem_take()(line 527). The usage fault is invoked.thread apply all bt:
Im at a point where im starting to think where this might not be a fault in my code anymore. Im running zephyr on a STM32l1.
The program shows the following output:
the main.c:
prj.conf:
On request I will send the driver code (or else this post might be a little to lengthy (its 2000 LoC), to properly read). Zephyr version is 3.0.99.