HardFault in PendSV_Handler when using FSL I2C FreeRTOS driver

Kernel
#1

aneedles wrote on Friday, May 17, 2019:

I am using developing on a MK66 custom board, using GCC in MCUXpresso (Eclipse), with FreeRTOS Kernel V10.0.1.

I sucessfully utilized the FSL I2C driver to use the MCU peripheral and wanted to transition to a FreeRTOS non-blocking version. However, I am getting a HardFault seemingly upon a taskENTER_CRITICAL() call in xQueueSemaphoreTake. Using the “Debugging a ARM Cortex-M Hard Fault” method, I receive the core register values right as the HardFault occured as follows:

r0: 4294967260
r1: 536872372
r2: 536872368
r3: 536891636
r12: 0
lr: 4294967289
pc: 1110
psr: 553672718

At the address of 1110 (0x456) we are in the middle of PendSV_Handler as follows:

> PendSV_Handler:
> 00000440:   mrs     r0, PSP
> 00000444:   isb     sy
> 00000448:   ldr     r3, [pc, #84]   ; (0x4a0 <PendSV_Handler+96>)
> 0000044a:   ldr     r2, [r3, #0]
> 0000044c:   tst.w   lr, #16
> 00000450:   it      eq
> 00000452:   vstmdbeq        r0!, {s16-s31}
> 00000456:   stmdb   r0!, {r4, r5, r6, r7, r8, r9, r10, r11, lr}
> 0000045a:   str     r0, [r2, #0]
> 0000045c:   stmdb   sp!, {r0, r3}
> 00000460:   mov.w   r0, #160        ; 0xa0
> 00000464:   msr     BASEPRI, r0
> 00000468:   dsb     sy
> 0000046c:   isb     sy
> 00000470:   bl      0x24a8 <vTaskSwitchContext>
> 00000474:   mov.w   r0, #0
> 00000478:   msr     BASEPRI, r0
> 0000047c:   pop     {r0, r3}

I’m lost in what to really do with this information. Basically, I am able to pass through the kENTER_CRITICAL() one time, observe I2C operation, but the the second entering of kENTER_CRITICAL() HardFaults.

#2

rtel wrote on Saturday, May 18, 2019:

Is taskENTER_CRITICAL() getting called from an interrupt service
routine? That would happen if you call a FreeRTOS API function from the
routine. If you have configASSERT() defined then it should hit the
assert as you need to use the interrupt safe alternatives to the macros.
If you are still stuck then please post the ISR code too.

#3

aneedles wrote on Saturday, May 18, 2019:

#4

aneedles wrote on Saturday, May 18, 2019:

Hi Richard! No, I am not calling taskENTER_CRITICAL from an ISR. I actually am not using any ISRs yet. I have configASSERT defined, but it never gets caught there.