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 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...
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: ");
// /* Services initialization */
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?
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.
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.