FreeRTOS Usage Fault

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ToPe_1312931
Level 4
Level 4
10 replies posted 10 questions asked 5 replies posted

I have code that runs just fine with 2 tasks for a random amount of time and then I get a UsageFault. The time to the fault ranges from a few minutes to a few hours, so is very hard to determine what is causing the fault. Any suggestions on how to figure out what is wrong? Stack trace attached. Thanks!

ToPe_1312931_0-1621962104835.png

 

 

0 Likes
1 Solution
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @ToPe_1312931 ,

I used the same Cy_SysLib_ProcessingFault () to see the logs. I simply tried to print debug messages from either task and tried to find out the last executed task before entering the hard fault. Also, I could not reproduce the issue when I commented out the SPI transfer portion of the SPI task. Can you try to use low level SPI writes to avoid SPI interrupts to see if you can avoid the issue?

Regards,
Bragadeesh

View solution in original post

0 Likes
14 Replies
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @ToPe_1312931 ,

It is difficult to spot the issue with this call stack alone. Would you be able to send us the archive of the project along with the FreeRTOSconfig.h so that we can find the root cause of the issue?

Regards,
Bragadeesh
0 Likes
lock attach
Attachments are accessible only for community members.

Here is the zip file.

0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @ToPe_1312931 ,

We could not reproduce this issue at our end. Can you please let us know if there are any stack overflow errors in the code? Also try increasing the stack size to avoid any stack overflow issue.

 

Regards,
Bragadeesh
0 Likes

Did you have something reading the USB port? If not the software sits waiting for a USB connection and never runs FreeRTOS. I use a Python script on a host computer connected to the PSoC non-kit3 USB port. I did double the FreeRTOS stack and still get the problem.

Here is my Python script:

import serial
import time

s=serial.Serial('/dev/ttyACM0', 115200)
f=open('psoc.bin', 'w')
while 1:
c=s.read()
t=time.time()
f.write(str(t) + ',' + hex(ord(c)) + '\n')
f.close()

0 Likes

These 3 lines need to be indented:

c=s.read()
t=time.time()
f.write(str(t) + ',' + hex(ord(c)) + '\n')

0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @ToPe_1312931 ,

I had connected the device to the Term term to ensure that the code is not stuck at Cy_USB_Dev_CDC_IsReady(). Now, I'm running your script at the background to ensure that we have the same environment. However, I'm using a windows PC as the host.

I haven't run into the error yet. We will have to find the reason for the usage fault. According to the CM4 Usage fault , an usage fault could occur due to several reasons such as executing an invalid instruction, stack overflow , divide by 0 operation , unaligned load or store access etc.

To find out what is the reason for the usage fault you need to check the UsageFault Status Register (UFSR) status register.  Can you please let us know the status of this register.

The following code example helps you decode CM4 usage fault. 

https://www.cypress.com/documentation/code-examples/ce218541-psoc-6-mcu-fault-handling-basics

Regards,
Bragadeesh
0 Likes

Implemented the Cy_SysLib_ProcessingFault function. It gets hit. The cy_faultFrame.pc is 0x0802491C, which is not in the disassembly.

0 Likes

cfsr is 0x00000100

0 Likes

cfsr.cfsrBits.iBusErr is set to 1

ToPe_1312931_0-1623004656573.png

 

0 Likes
Ekta_N
Moderator
Moderator
Moderator
750 replies posted First like given 250 solutions authored

Hi @ToPe_1312931 ,

In your project I see that you have used the Cy_USB_Dev_CDC_IsReady function is used in the UARTTask function. The while loop: while (!Cy_USB_Dev_CDC_IsReady(USBUART_COM_PORT, &USBUART_cdcContext)); will cause the program to be stuck at this line until USB In Endpoint is finally ready to send data to the Host.

Instead you can try using the function Cy_USBFS_Dev_Drv_RegisterEndpointCallback() to registers a callback function to notify of an endpoint transfer completion event in Cy_USBFS_Dev_Drv_Interrupt. In case of an IN endpoint this means that the Host has read data from the endpoint and new data can be loaded.

You can then load the data in the callback back function registered.

For more details you can refer to the PDL API Reference Guide 

Thanks and Regards

Ekta

 

0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @ToPe_1312931 ,

Thank you for sharing the screenshots. I was able to reproduce the issue once after hours of running. From debug logs it looks like some corruption in one of these registers that has resulted in a usage fault. However, this occurs very rarely and I'm not able to reproduce this fault often.

What I noticed was the fault happening in the SPI task. I suspect this could be some issue with the SPI interrupt. Since you are anyways blocking the task till the SPI transaction is complete, can you try to use low level SPI (non interrupt based functions) to perform SPI transfer. Also it is a good practice to use Semaphore to unblock the task from  interrupts instead of blocking using TaskDelay().

Regards,
Bragadeesh
0 Likes

Thanks for the information. You say "From debug logs it looks like some corruption in one of these registers that has resulted in a usage fault". Where are these logs? You also say "What I noticed was the fault happening in the SPI task." How did you determine that? I appreciate the help!

0 Likes
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi @ToPe_1312931 ,

I used the same Cy_SysLib_ProcessingFault () to see the logs. I simply tried to print debug messages from either task and tried to find out the last executed task before entering the hard fault. Also, I could not reproduce the issue when I commented out the SPI transfer portion of the SPI task. Can you try to use low level SPI writes to avoid SPI interrupts to see if you can avoid the issue?

Regards,
Bragadeesh
0 Likes

Implemented the low-level SPI on Friday and the application is still running this Monday morning.