You are here

Hardfault (usagefault) exception while switching between threads - Processor switching to ARM state | Cypress Semiconductor

Hardfault (usagefault) exception while switching between threads - Processor switching to ARM state

Summary: 1 Reply, Latest post by LookAtSystemSolutions on 04 Jul 2012 10:43 PM PDT
Verified Answers: 0
Last post
Log in to post new comments.
ArunSP's picture
1 post

Iam working on porting an OS to Cypress - CY8C55 - AXI 060. Im using PSOC5 creator as the IDE and GNU GCC 4.4.1 tools for compiling.

I created  few threads of same priority: a simple thread which sends serial messages(UART send by polling).

First, a thread (say thread A) runs for its time slice followed by, the next thread (say thread B) running for its time slice. When the thread B completes its running and context switches to the third thread (say thread C), hard fault exception occurs.

Register Values dumped in Hardfault handler as suggested by Joseph Yiu :

R0 = d;      R1 = 1;      R2 = 9;      R3 = 0;      R12 = 81f4
LR [R14] = 0  subroutine call return address;      PC [R15] = 0  program counter;      PSR = 60000000
BFAR = e000ed38;    CFSR = 20000;    HFSR = 40000000;    DFSR = 0;    AFSR = 0;     BFSR = 200
UFSR = 2;    MMFSR = 20000;    CCR = 200;    SCB_SHCSR = 0;

In the hardfault region i also dumped the stack region around stack pointer of processor saved registers:

Memory - Value 
1fff9c30 - d;
1fff9c34 - 1; 
1fff9c38 - 9;
1fff9c3c - 81f4;  
1fff9c40 - 8200;
1fff9c44 - 24db;
1fff9c48 - 40c;
1fff9c4c - 61000000;

From the dumped register values, i noticed that xPSR value is 60000000. In cortex M3 TRM, it says 24th bit (the Thumb bit)should always be 1(thumb state), otherwise it would cause an usage fault exception.

For us, the Thumb bit is cleared , while thread switching happens, which is evident from the register value. But in the dumped memory region the value of saved xPSR value is 61000000. I couldnt figure out what causes this bit in the xPSR register to change from 1 to 0.

I would highly appreciate your efforts to support us.

LookAtSystemSolutions's picture
31 posts

Let me ask a few questions

1. Did you successfully run your OS on any other Cortex-M3 device?

2. How much does your OS mess with the stack?

3. Did this OS run on any other architecture before?

In all liklyhood your issue has nothing to do with PSoC but with exception handling in the Cortex-M3. You checked for J Liu, that was a very good idea, he is extremly knowledgable about the Cortex-M.

With your information it is not possible (at least for me) to reconstruct what you might have done.


Log in to post new comments.