[FreeRTOS] [LCD 128x64] My Application Program is Running fine with CY8CKIT-050 but in my Hardware it hangs on CY_ISR(IntDefault

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

cross mob
Anonymous
Not applicable

Hi there,
I am facing weird problem with my Application on PSoC 5 based hardware. This application is based on FreeRTOS, and application contains 128×64 kind of monochromatic LCD (Graphical LCD), having controller like ks0107.

   

We are attaching:
1. Application program for CY8CKIT-050.
2. Application program for our Hardware. (Only with different PIN usage)

   

The problem is that if we run this program with the PIN used for CY8CKIT-050, it runs smoothly and complete every task as desired with no problem at all. But if we only change the MCU PINs as used in our Hardware and program the Hardware MCU with same program, application runs to certain point and then hang. We tried debug mode and found out that after running for some time application goes to :

   
    

CY_ISR(IntDefaultHandler)
{

    

    while(1)
    {
        /***********************************************************************
        * We must not get here. If we do, a serious problem occurs, so go
        * into an infinite loop.
        ***********************************************************************/
    }
}

   
   

which is in Cm3Start.c. And at this point application stays in hanged state.

   

Here please note that this only happens if we used the same program in our Hardware. But if we use it in Kit (CY8CKIT-050), it runs completely fine without any fault.

   

We would like to also share that we have used FreeRTOS prior to this application, and we have successfully built applications with FreeRTOS.

   

Will you please check this files and see if we have made any mistake anywhere?

0 Likes
10 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

As the message states: Something serious has happened. Would help at least a bit to analyze the call stack.

   

What exactly has happened you will see in Call Stack.

   

Could be: IMO or ILO Clock not started

   

Invalid instruction

   

Stack clobbered (easy done in an RTROS)

   

Invalid memory reference

   

...and some more reasons.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

   

I am attaching my Call stack screenshot. Hope you may find out any fault. As this is the first time I have requirement to see this window "call stack", so I can not comment on anything. Sorry for my ignorance, but I am sure anyone here will throw some light here.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

You have got a problem in RTOS. At line 2244 in tasks.c an error occured. Look at that line (double click on call stack line), evolve what it should perform and see what to do. Seemingly has to do with stack requirements.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

   

But in second try I found this attached pic, in this pic it shows different memory location, this shows different location every time I stop-reprogram in debug mode-Run-Program Fualt Pause. I am confused here... The location you suggested is from FreeRTOS file, which I never modified.

   

And again why this runs competently fine with the CY8CKIT-050?

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Did you check the stack and heap settings for the project? I'm not familiar with FreeRTOS, but there surely have to be some changes made.

   

Show .cydwr file and open the system tab. Check with RTOS requirements.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

This conversation is going on in parallel:

   

https://sourceforge.net/p/freertos/discussion/382005/thread/17f86b2a/

   

Richard (FreeRTOS)

0 Likes
Anonymous
Not applicable

Hi Richard and Bob,

   

Thanks for the reply.

   

@Richard, yes parallel thread is going on the forum for freeRTOS also and I will update solution to both the thread, if this problem get solved from either. Thanks for the help.

   

@Bob, yes I double and triple check and the heap and stack setting from cydwr screen, attached pic is my current setting. But I have also tried different setting with no success, every time it got stuck in the same loop. But the call stack window shows random information every time. If you exprert people find some other setting please that will be great help.

   

I just followed the demos over this links and set heap and stack for the FreeRTOSConfig.h and cydwr system setting acordingly.

   

http://www.cypress.com/blog/psoc-creator-news-and-information/psoc-demos-freertos

   

http://community.arm.com/community/arm-partner-directory/partner-cypress/blog/2014/03/31/new-demos-f...

   

http://interactive.freertos.org/forums/191896-Cypress

   

and for the same setting the application runs smooth for the CY8CKIT-050 with no problem at all. It just hang in my hardware.

0 Likes
Anonymous
Not applicable

Hi there,

   

Please can you see my problem and find the mistakes I am making, I am waiting for it to be solve. Thanks in Advance.

0 Likes
Anonymous
Not applicable

Finally found the cause of the problem.

   

NVIC_HARD_FAULT_STATUS : Hard Fault Status Register : Address = 0xe000ed2c

   

This register has value 0x40000000, which means:  

   

Hard Fault activated because a Configurable Fault was received and cannot activate because of priority or because the Configurable Fault is disabled. The Hard Fault handler then has to read the other fault status registers to determine cause.

   

NVIC_USAGE_FAULT_STATUS : Usage Fault Status Register : Address = 0xe000ed2a

   

This register has value 0x0001, which means:

   

UNDEFINSTR : The UNDEFINSTR flag is set when the processor attempts to execute an undefined instruction. This is an instruction that the processor cannot decode. The return PC points to the undefined instruction.

   

Now what this means? I cannot find the details about why this is happened and how to resolve. Please help me here.

   

   

 

   

0 Likes
Anonymous
Not applicable

We have replaced the MCU with fresh chip, and application is running fine. So we concluded that there must be some problem in MCU. As of now we are going ahed with this.

0 Likes