[PSoC 5] [LCD 128x64] My Application Program is Running fine with CY8CKIT-050 but in my Hardware it hangs on CY_ISR(IntDefaultHandler) in file name "Cm3Start.c"

dhruvacharya wrote on Friday, October 02, 2015:

Hi there,
As this prvGetRegistersFromStack had given successfully the copy of the last stack, Is there any way I can put this stack back to my system memory (i.e. manual pop) and then do the stack dump.

Of course, this isn’t always helpful when you end up at the hard fault because of popping stuff off of a blown stack or stomping on stuff in memory. You generally tend to corrupt a bunch of the important registers, return back to some crazy spot in memory, and then execute whatever’s there. You can end up hard faulting many thousands time.

But Is there any way I can go back to the problematic location and see what actually happening? I am thinking of comparing what is needed and what is available which generated this hard fault.

dhruvacharya wrote on Friday, October 02, 2015:

Hi there,

But here what is mysterious for me is that now I have made some changes with my Kit CY8CKIT-050, and PIN usage for both the Kit and my Hardware is same now.

If I run the program in KIT, it never reaches to any exception handler or any default interrupt handler and program runs smoothly and do what is suppose to do. But if I Run this same program with my hardware, It always ends up in the Hard Fault Exception handler and from that it reaches to prvGetRegistersFromStack

One other thing is that If I make small changes in my application, ever time the location given by the registers from prvGetRegistersFromStack comes out to be different. So what is causing this problem?

I am also attaching whole workspace project for the PSoC Creator, if it may help someone, to design the exception handler.

heinbali01 wrote on Friday, October 02, 2015:

Hi Dhruv,

I had a short look at your source code. It is all very up-to-date and I didn’t see strange things.

You install a DMA interrupt:

    GLCD_DMA_INT_StartEx(vGLCD_DMA_ISR);

before the tasks are created. Within the ISR’s you do not test the validity of xGLCD_TaskHandle. But as you have configASSERT() defined, it can not cause an exception.

The hardware priority of the interrupt seems OK to me: it is the lowest interrupt (7 << 5)
Where configMAX_SYSCALL_INTERRUPT_PRIORITY is higher (5 << 5) (numerical it is lower).

A note about masking interrupts:

 CY_ISR(vGLCD_DMA_ISR)
 {
     ...
     /* Mask off the other RTOS interrupts to interact with the queue. */
-    ulMask = portSET_INTERRUPT_MASK_FROM_ISR();
     ...
-    portCLEAR_INTERRUPT_MASK_FROM_ISR( ulMask );
 

I wonder if the masking is really necessary? Could you leave-out the SET/CLEAR couple and test it?

But if I Run this same program with my hardware, It always
ends up in the Hard Fault Exception handler
Is your hardware well-tested? Do you add external memories? Are they OK?

ever time the location given by the registers from
prvGetRegistersFromStack comes out to be different
Isn’t that normal, that functions always end-up in a different location after changing code?

A minor remark about your code:
When you declare data which will never change, use the word “const”:

-    char text2[] = "Galaxy Electronics\0";
+    const char text2[] = "Galaxy Electronics";

The addition of “\0” in a string is not necessary, the compiler already does that for you.

-uint8 CYXDATA u8GLCDPages[24] =     
+const uint8 CYXDATA u8GLCDPages[24] =     
 {                                
     0x3F,    //  Turn on the display at 0, rest can be any (0x00)
     0xB8,    //SET_PAGE 0                       
     0x40,    //SET_ADDRES 0                               
     ...

When declared as “const”, this data doesn’t occupy any space in RAM.

Regards.

heinbali01 wrote on Friday, October 02, 2015:

#define vMonitor_Task_Stack				( 5 * configMINIMAL_STACK_SIZE )
#define vGLCD_Task_Stack				( 1 * configMINIMAL_STACK_SIZE )
#define vGLCD_GEMain_Task_Stack			( 3 * configMINIMAL_STACK_SIZE )

Although you do have configCHECK_FOR_STACK_OVERFLOW defined, when using a minimal stack size, it may happen that the application crashes before the stack check can even be done.

dhruvacharya wrote on Friday, October 02, 2015:

Hi @Hein,

After your suggestion I have tested with this:

You install a DMA interrupt:

GLCD_DMA_INT_StartEx(vGLCD_DMA_ISR);

before the tasks are created.

This is done. I have called this after the Task Created.

GLCD_DMA_INT_StartEx(vGLCD_DMA_ISR);
GLCDPWM_1_Start();
GLCDPWM_2_Start();

GLCD_UPDATE_Write(0);

A note about masking interrupts:

CY_ISR(vGLCD_DMA_ISR)
 {
     ...
     /* Mask off the other RTOS interrupts to interact with the queue. */
-    ulMask = portSET_INTERRUPT_MASK_FROM_ISR();
     ...
-    portCLEAR_INTERRUPT_MASK_FROM_ISR( ulMask );

I wonder if the masking is really necessary? Could you leave-out the SET/CLEAR couple and test it?

This is also done. Commented SET-CLEAR Couple

When you declare data which will never change, use the word “const”:

-    char text2[] = "Galaxy Electronics\0";
+    const char text2[] = "Galaxy Electronics";

The addition of “\0” in a string is not necessary, the compiler already does that for you.

This is also done.

-uint8 CYXDATA u8GLCDPages[24] =     
+const uint8 CYXDATA u8GLCDPages[24] =     
 {                                
     0x3F,    //  Turn on the display at 0, rest can be any (0x00)
     0xB8,    //SET_PAGE 0                       
     0x40,    //SET_ADDRES 0                               
     ...

When declared as “const”, this data doesn’t occupy any space in RAM.

I tried this, but didn’t worked because I think u8GLCDPages is used in the some definition of the TDs of DMA, and it only accept the RAM location. So changed back to original and application is working again with hard fault occured.

But I think with KIT I was using the same code before your comments and application is running, and in Hardware it goes to Hard Fault Handler. I cann’t understand why this is so?

Now for the stack comments:

In FreeRTOSConfig.h:

#define configUSE_PREEMPTION		1
#define configUSE_IDLE_HOOK			0
#define configMAX_PRIORITIES		( 6 )
#define configUSE_TICK_HOOK			0
#define configCPU_CLOCK_HZ			( ( unsigned long ) BCLK__BUS_CLK__HZ )
#define configTICK_RATE_HZ			( ( TickType_t ) 1000 )
#define configMINIMAL_STACK_SIZE	( ( unsigned short ) 100 )
#define configTOTAL_HEAP_SIZE		( ( size_t ) ( 32 * 1024 ) )
#define configMAX_TASK_NAME_LEN		( 25 )
#define configUSE_TRACE_FACILITY	0
#define configUSE_16_BIT_TICKS		0
#define configIDLE_SHOULD_YIELD		0
#define configUSE_CO_ROUTINES 		0
#define configUSE_MUTEXES			1

And in TaskStack.h

#define vMonitor_Task_Stack			( 5 * configMINIMAL_STACK_SIZE )
#define vGLCD_Task_Stack			( 10 * configMINIMAL_STACK_SIZE )
#define vGLCD_GEMain_Task_Stack		( 5 * configMINIMAL_STACK_SIZE )

But again same problem of going into hard fault handler, just the contains of the register from prvGetRegistersFromStack chaged. Thanks again.

heinbali01 wrote on Friday, October 02, 2015:

But I think with KIT I was using the same code before your
comments and application is running, and in Hardware it goes
to Hard Fault Handler. I can’t understand why this is so?

Me neither :frowning: All I can suggest is to compare the 2 prints in detail (X-tal, memories) and to test everything (memory test, all connections) and hopefully you will find a difference that explains it.

Hein

dhruvacharya wrote on Saturday, October 03, 2015:

Hi @Hein,

From the day 1, we have tested and checked this PIN and Crystal, and there was no problem. But after your suggestion, we again consider to recheck, and we were here at work for whole night (As here it was night in this part of world), we have tested for each PIN, and it was fine. After that we have made a new program from scratch for the Hardware, doing same work, but not using FreeRTOS just normal C program without OS, and it was running fine without any problem.

So we think that there is no problem at all for the PINs and XTAL in hardware at all.

We even tried to program the KIT with it (Non OS Program) and it was running fine with KIT also.

But even if there is some other way in your mind to check for the PINs-Crystal-Memory, please convey the idea, we will give it a try. We want to use FreeRTOS with this and we will do whatever it takes for fault less operation. Thanks again for your detailed help, you people are saving life.

heinbali01 wrote on Sunday, October 04, 2015:

Hi Dhruv,

If you want, send an email to h dot tibosch at freertos dot org
The subject isn’t interesting anymore for most users, and sending emails is a bit quicker than using a forum. If you find a solution you can still post it here :slight_smile:

Regards.

dhruvacharya wrote on Tuesday, October 20, 2015:

Hi there,

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.