4 Replies Latest reply on Jul 14, 2018 10:27 PM by rjks

    CY_ISR(IntDefaultHandler) on only 1 of 3 modules

    daniel.havener_3520906

      Odd question (and I've got more debugging to do):

       

      I've got 3 development boards. Basic HeartRate Sensor example runs great on 2 of the 3 boards. On the 3rd board, I get dumped into the IntDefaultHandler at the BLE_Start() call. Stepping through the code, the offending call (again, on only 1 set of the hardware) is CyBle_StackInit().

      Breakpoint at the first/initial return to the Handler (CYBLE_EVT_STACK_ON) never hits.

       

      Further complicating this is, I can fire some simple code with just digital I/O, timers, and UARTs and it will run flawlessly (into the offending hardware).  Any big brain, experienced ideas out there on what can/could be going wrong w/n the PSoC4 on the 1 set of hardware that is fine on the other 2?

       

      Physical inspection of the pins doesn't show anything obvious, but I'm thinking that this could just be a bad part? Or part that maybe got ESD'd during placement on the board? Anyone seen that happen.

        • 1. Re: CY_ISR(IntDefaultHandler) on only 1 of 3 modules
          rjks

          Hi Daniel,

           

          1. Are these the custom boards or Cypress Kits? Are all the board identical?

           

          2. Can you send us the call stack when the fault occurs?

           

          3. You mentioned other designs works well and only the BLE design which leads to hardfault. I think you are using the IMO as clock source, can you check by routing the ECO to the HFCLK and run the designs without BLE?

          This is to ensure the ECO is working fine and not causing the fault you are seeing.

           

          Thanks,

          Ranjith

          • 2. Re: CY_ISR(IntDefaultHandler) on only 1 of 3 modules
            daniel.havener_3520906

            Ranjith,

             

            Thanks for answering so quickly!

             

            1. Custom Boards. Fairly simple (li-ion battery, solar panel, single sensor / digital input, battery level monitor).

            So, using the HeartRate Sensor example as a base. I've got a second code base (mentioned above) that is just built up from the bi-directional UART example.  The HeartRate Sensor example (with some simple moving of LED pins, and bringing in my UART items and code) runs great on 2 of the boards, the 3rd is my "bad" board.

             

            2. Call Stack

            0 IntDefaultHandler() Generated_Source\PSoC4\Cm0Start.c 140 0x0000124A (All)

            1 <signal handler called>() ?????? ?????? 0xFFFFFFF9 (All)

            2 CyBLE_Bless_RfRegWrite(reg32 * blessAddr = 0x402e10d8, const uint16 regValue = 88) Generated_Source\PSoC4\CYBLE_HAL_PVT.c 338 0x000038E4 (All)

            3 CyBleStackMgr_SetClockParam() ?????? ?????? 0x000054D0 (All)

            4 CyBleStackMgr_BleSSInit() ?????? ?????? 0x00005228 (All)

            5 CyBleStackMgr_Init() ?????? ?????? 0x00004704 (All)

            6 CyBle_StackInit() ?????? ?????? 0x00004492 (All)

            7 CyBle_Start(CYBLE_CALLBACK_T callbackFunc = 0x4cd <AppCallBack>) Generated_Source\PSoC4\CYBLE.c 481 0x00001B16 (All)

            8 main() main.c 475 0x000007F4 (All)

             

            So, looks like CyBLE_BlessRfRegWrite() ?

             

            3. Working through your clock suggestion now...

            • 3. Re: CY_ISR(IntDefaultHandler) on only 1 of 3 modules
              daniel.havener_3520906

              Ranjith,

               

              Did 2 things with the troublesome board.

               

              1. Commented out the following block in main()

                  /* Start CYBLE component and register generic event handler */

              //    apiResult = CyBle_Start(AppCallBack);

              //    if(apiResult != CYBLE_ERROR_OK)

              // {

              // DBG_PRINTF("CyBle_Start API Error: ");

              //        PrintApiResult();

              // }

              //   

              //    PrintStackVersion();

              //   

              //    /* Services initialization */

              //    BasInit();

              //    HrsInit();

               

              Taking this block out and the board runs fine (UARTs, Digital Inputs, ADC). Really thinking this may be either a bad part, or shorted/missed connection during board population by the board shop.

               

              2. Used ECO to source HFCLK (by selecting ECO for Direct_Sel)

              Leaving the above blocked commented, code runs fine.

              Uncomment (putting BLE_Start() back in play); code falls back into IntDefaultHandler() and call stack looks just like above.

               

              Anything else you can think to help eliminate it being something on the part itself? At this point, I'm pretty settled that it's a hardware problem, just wanting to learn some things about troubleshooting if it's with the PCoC4 part, or with the board shop? Any way to tell?

              • 4. Re: CY_ISR(IntDefaultHandler) on only 1 of 3 modules
                rjks

                Hi Daniel,

                 

                The call stack shows that the fault happened when writing the first register. This is expected when the clock is not available by the time this instruction is executed (because of crystal taking unusually long time to startup). The issue seems to be ECO startup time related.

                 

                You can refer to the below doc for details on ECO selection and tuning, please ensure that the crystal you have used meets the requirement mentioned in the below document.

                http://www.cypress.com/file/139476/download

                 

                 

                For testing purposes set the please configure the CAPTRIM value to the lowest value in the CYDWR file. Open the clocks page and click on the Configure button inside the ECO box and change the value ( Enter 0, it will automatically switch to the lowest supported value). This will reduce the start up time.

                 

                Please check if this solves the issue. If it works, then you can work on tuning the CAPTRIM values as described in the document.

                 

                Thanks,

                Ranjith