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.
Hi Gaurav,
I had a doubt in context of running example task and then handling irq interupt randomly,
Scenario:-
I had run a example task in my Cortex-R4 and kept a while loop in example task which runs until the condition becomes false using a variable!=1 in CR4 core.
I am triggering irq or external interrupt(0x18) to CR4 from different core(CM4) and inside interrupt handler make the variable value to one so that execution comes out of while loop in example task.
Here i see that once after interrupt handling, example task doesn’t run normally. Basically PC jumps to example task and then after few instruction code info.zip (936 Bytes)
it jumps to svc handler(0x08) or undefined instruction handler(0x04). Does the irq handler code FreeRTOS_IRQ_Handler and example task looks fine? or any changes required here?
I am debugging more on below register contents during the time of issue. but let me know if code looks fine attached here
0x001b022c in exampleTask (parameters=) at application/main.c:101
101 application/main.c: No such file or directory.
1: x/i $pc
=> 0x1b022c <exampleTask+92>: movs r1, #1
(gdb)
0x001b0230 101 in application/main.c
1: x/i $pc
=> 0x1b0230 <exampleTask+96>: cmp r3, r0
(gdb)
0x001b0234 112 in application/main.c
1: x/i $pc
=> 0x1b0234 <exampleTask+100>: ldr.w r3, [r12]
(gdb)
0x00000004 in ?? ()
1: x/i $pc
Hi @sitikela
Looking at your FreeRTOS_IRQ_Handler , is there a reason why the following lines are commented out ?
/* Call the interrupt handler. */
# PUSH {r0-r3, lr}
LDR r2, =irqctConst /*; Load address of the variable into r0*/
LDR r1, [r2] /*; Load the value of the variable into r1*/
ADD r1, r1, #1 /*; Increment r1 by 1*/
STR r1, [r2] /*; Store the incremented value back into memory*/
TRACE(0x6)
LDR r1, vApplicationIRQHandlerConst
BLX r1
# POP {r0-r3, lr}
# ADD sp, sp, r2
This ensures (LR) is saved properly.
Also, BX LR is dangerous if SPSR isn’t restored correctly.
Hi Rahul,
i have uncommented the lines as mentioned by you and changed “BX LR” with movs pc, LR. But if i don’t use BX, the code continuously calls the vApplicationIRQHandlerConst handler even after clearing the interupt status. Below is my latest code and i have doubt on “Movs” vs “BX” instructions here
.align 4
.type FreeRTOS_IRQ_Handler, %function
FreeRTOS_IRQ_Handler:
/* Return to the interrupted instruction. */
SUB lr, lr, #4
/* Push the return address and SPSR. */
PUSH {lr}
MRS lr, SPSR
PUSH {lr}
/* Change to supervisor mode to allow reentry. */
CPS #0x13
/* Push used registers. */
PUSH {r0-r3, r12}
/* Ensure bit 2 of the stack pointer is clear. r2 holds the bit 2 value for
future use. */
MOV r0, sp
AND r2, r0, #4
SUB sp, sp, r2
/* Call the interrupt handler. */
PUSH {r0-r3, lr}
LDR r1, vApplicationIRQHandlerConst
BLX r1
POP {r0-r3, lr}
ADD sp, sp, r2
CPSID i
DSB
ISB
POP {r0-r3, r12}
CPS #IRQ_MODE
/*CPS #FIQ_MODE*/
POP {LR}
MSR SPSR_cxsf, LR
POP {LR}
MOVS PC, LR
Can you confirm the variable interrupt_var is declared as volatile.
If interrupt_var is modified inside an IRQ handler, the compiler must not optimize access to it. Otherwise, the while(interrupt_var != 1) loop may get compiled as an infinite loop.