0

PSoC Creator FreeRTOS PSoC 5 CY8C5868AXI-LP035 GLCD 128x64

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.

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.

Attaching(as I don't know how to attach I am providing Google drive links):

  1. Application program for CY8CKIT-050 here.

  2. Application program for our Hardware here (Only with different PIN usage)

Call Stack window screen shot where problem occurs:

Call Stack 1

Call Stack 2

PS: This discussion is going on in parallel at

  1. Cypress Community Forum

  2. FreeRTOS Forum

  3. Other Forum

Sami Kuhmonen
  • 30,146
  • 9
  • 61
  • 74
Dhruv Acharya
  • 19
  • 5
  • I doubt this is a software issue. It sounds like you either misconfigured the port, or more likely, you have some sort of hardware problem which is causing interrupts. Start by investigating which interrupt you are getting, then take it from there. – Lundin Sep 29 '15 at 14:19
  • Hi Lundin. Thax for the comment, First I also doubt about that but then I have (also attached) **call stack windows**, which shows that there is no **external Interrupt** that called this Handler. – Dhruv Acharya Sep 29 '15 at 14:51
  • Finally found the cause of the problem. **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. – Dhruv Acharya Oct 01 '15 at 15:19
  • Ah ok, it probably means somewhere in your program you have a memory corruption bug, where the program is writing outside allocated memory and destroys other data. For example you could have a function that destroys its own call stack. The bug would then manifest itself when you return from that function, because the return address has then been destroyed. So the program will instead jump to a random location and attempt to execute program code there. But since the contents on that address is not valid op codes, you get a hardware exception. – Lundin Oct 02 '15 at 06:19
  • Also, the bug could be caused by an interrupt vector table which isn't programmed, i.e there is a regular interrupt occuring, but inside the interrupt vector table, there no address specified for the interrupt service routine. – Lundin Oct 02 '15 at 06:23
  • I have gone through this [link](http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html) and made the **hard fault exception handler** which executes every time this fault occur. And it calls the **prvGetRegistersFromStack**. This **prvGetRegistersFromStack()** copies the register values from the stack into the C variables, then sits in a loop.By which I have found that fault occurs every time when PC at location 0x0000270C. In that location there is use of R2 end R3 and R2 contains the **0xFFFFFFFF**. This seems overflowed value. I don't know why. I will provide code. – Dhruv Acharya Oct 02 '15 at 06:41
  • My dis-assembly window around that location is: `0x000026FC str.w r2, [r3, #1d4] ; 0x1d4 0x00002700 bx lr 0x00002702 push {r4, lr} 0x00002704 ldr r3, [pc, #ac] ; (27b4 ) 0x00002706 movs r2, #0 0x00002708 str.w r2, [r3, #1d4] ; 0x1d4 0x0000270C ldr.w r2, [r3, #1ac] ; 0x1ac 0x00002710 ldr r2, [r2, #0] 0x00002712 ldr.w r3, [r3, #1ac] ; 0x1ac` – Dhruv Acharya Oct 02 '15 at 06:49
  • It is not meaningful to watch the disassembly, you have to check which C function that is allocated on that address (check map file) and then go through the C code in search for pointer-related bugs. Also check the stack pointer when this occurs, so you can rule out stack overflow. – Lundin Oct 02 '15 at 08:37
  • Yes I think it is not meaningful, as if I change some small thing in the software, the fault location which I get from **prvGetRegistersFromStack()** changes. So I don't think it is some issue with fixed location. I thinks that it is the issue like Stack and / or Heap reaches at its Boundary location and further operation corrupts memory, which is being read indirectly. Now I can find the location at which this happens but Now I don't know how to resolve it. – Dhruv Acharya Oct 02 '15 at 12:26
  • When the bug strikes, check the stack pointer. If you can't do that, then use the old school stack usage trick, which goes as follows: Check at which address your stack starts and ends. Download your program to the MCU through a debugger. Before starting, set all memory cells of the stack to some junk value like 0xAA. Stop at the crash. See how deep into the stack you still find 0xAA memory cells. – Lundin Oct 02 '15 at 13:08
  • 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 ahead with this. – Dhruv Acharya Oct 20 '15 at 13:59
  • So my initial gut instinct was correct :) "...or more likely, you have some sort of hardware problem which is causing interrupts". – Lundin Oct 20 '15 at 14:03

0 Answers0