Hi Gaurav/Rahul,
Currently FreeRtos porting is completed and i am able to schedule 2 tasks and see task switching is also happening properly. Thank you for the continuous support.
I had a followup query on this task as below:-
On top of FreeRtos i have added our own bluetooth stack and when i tried executing i had observed that during task switch instruction(rfeia sp!) the code jumps to data abort irq. I had captured registers in gdb just before this issue? specially i see prvTaskExitError in LR register is there any thing i can check here on the reason for this issue?
Hi Gaurav,
As per your suggestion i tried changing stack size and observed that the execution jumps to reset handler, below are the sizes i have set
1)increased stack size to 80kB from current 40kB
2)standard Heap size 5KB
3) FreeRTOS Heap size 95kB (configTOTAL_HEAP_SIZE)
->The code while running suddenly jumps to tr_rst and upon running backtrace, it points to xPortStartScheduler
Breakpoint 1, main () at application/main.c:168
168 application/main.c: No such file or directory.
1: x/i $pc
=> 0x1b0260 : push {r4, r5, r6, lr}
(gdb) c
Continuing.
Breakpoint 2, 0x001b0022 in tr_rst ()
1: x/i $pc
=> 0x1b0022 <tr_rst+2>: cpsid f
(gdb) bt #0 0x001b0022 in tr_rst () #1 0x001b273c in xPortStartScheduler () at FreeRTOS-Kernel-11.1.0/portable/GCC/ARM_CRx_No_GIC/port.c:243 #2 0x001b1dea in vTaskStartScheduler () at FreeRTOS-Kernel-11.1.0/tasks.c:3744 #3 0x001c06de in WsfOsEnterMainLoop () at packetCraft_BTStack/wsf/targets/freertos/sources/wsf_os.c:547 #4 0x001b2824 in fit_main_start () at packetCraft_BTStack/ble-apps/build/fit/fit_main_start.c:165 #5 0x001b02b2 in main () at application/main.c:205 #6 0x001c098e in setup ()
SP seems to be pointing to below address when reset handler is hit, how ever if i run again then code runs normally
sp 0x1ff7a4 0x1ff7a4
lr 0x1b273d 0x1b273d <xPortStartScheduler+44>
pc 0x1b0022 0x1b0022 <tr_rst+2>
cpsr 0x1f3 499
sp_usr 0x1e41f8 0x1e41f8 <uxTimerTaskStack.0+4084>
lr_usr 0x1b2581 0x1b2581
map file size and attaching output.map file for reference
._stack 0x001ebf88 0x1387c
0x001ebf88 . = ALIGN (0x4)
0x001ebf88 _sstack = .
0x001ff804 . = ((. + __STACK_SIZE) - 0x4)
Note:- we are running 1 application thread, 2 FreeRtos threads(jdle and timer) and 2 stack threads
Which stack size did you increase? Is it for the task running bluetooth?
Also, either in your linker script or in your startup code, you must be setting up stack sizes for various processor modes. Would you please increase them as well?
Do you mean to say that if you hit continue from the reset handler, it works? Or do you mean that it works after power cycle?
It is correct that your tasks start to run and then sometime later the application hits reset handler?
Hi ActoryOu,
the value for configCHECK_FOR_STACK_OVERFLOW is already set to 2 in our code but i don’t see the function vApplicationStackOverflowHook is getting called. I don’t see my prints in that function getting printed or not getting hit in gdb as a breakpoint when set explicitly.
Hi Gaurav,
Below are the responses for your query
q1) Which stack size did you increase? Is it for the task running bluetooth?
Also, either in your linker script or in your startup code, you must be setting up stack sizes for various processor modes. Would you please increase them as well?
A) I had increased the stack size in linker script that is for Supervisor Mode stack setup for FreeRtos not for bluetooth task.
for your second question of increasing stack size for other processor mode i tried changing below sizes but still reset handler is getting hit.
a) FIQ mode:- 500 Bytes(from 100Bytes)
b) SYS mode :- 20kB
c) Supervisor Mode:- 43 KB
Q2) Do you mean to say that if you hit continue from the reset handler, it works? Or do you mean that it works after power cycle?
A) Here i had kept breakpoint on reset Hanlder. So once reset Hanlder is hit during scheduling of task, i try giving continue option and from here the execution continues to main and example application task runs normally, no power cycle is done.
q3)It is correct that your tasks start to run and then sometime later the application hits reset handler?
A) No, during scheduleing phase only reset handler is hit without task scheduling and then if i give continue from reset handler again then example task runs. Below is the backtrace when reset hanlder hits.
Breakpoint 2, 0x001b0022 in tr_rst ()
(gdb) bt #0 0x001b0022 in tr_rst () #1 0x001b273c in xPortStartScheduler () at FreeRTOS-Kernel-11.1.0/portable/GCC/ARM_CRx_No_GIC/port.c:243 #2 0x001b1dea in vTaskStartScheduler () at FreeRTOS-Kernel-11.1.0/tasks.c:3744 #3 0x001c08ae in WsfOsEnterMainLoop () at packetCraft_BTStack/wsf/targets/freertos/sources/wsf_os.c:547 #4 0x001b2824 in fit_main_start () at packetCraft_BTStack/ble-apps/build/fit/fit_main_start.c:165 #5 0x001b02b2 in main () at application/main.c:205 #6 0x001c0b5e in setup ()
startup file.zip (6.2 KB)
Hi Gaurav,
Please find the attached startup and loader file
Q2) i am facing some issue in checking exact instruction causing this issue but below are my observations
a) if i disable the timer and check then for i observed in code of switch_before_exit for instruction (rfeia sp!) the exectution jumps to data abort handler
b) if we enable the timer and checked then data abort is not called instead reset hanlder is called. In this case-b we couldn’t check exact instruction since instead of task switching in (rfeia sp!) only fiq handler is called due to timeout of timer while debugging. It just points to xPortStartScheduler while backtrace command is invoked
Below code should have the address for irq_stack_end in startup file, you want me to add explicitly in loader file to have seperate section similar to fiq?
Line 581: #ifdef IRQMODE
.balign 16
irq_stack:
.rept (SVC_STACK_SIZE + (2 * STACK_SIGNATURE_DATA_SIZE))
.byte 0
.endr
irq_stack_end = . #endif
Hi Gaurav,
Actually we are not using irq interupt so i had commented it out but as per your suggestion i had allocated memory for irq stack in loader file, which i didn’t share to you. But still same crash issue was observed with that change also.