Hard fault in llh_isr_handler in bootloadable application

[ThBr_4364666]

Hello,

I have a bootloadable project set up as BLE a peripheral with LE secure and bonding data stored to emEEPROM. I'm experiencing a hard fault when connecting to a BLE central. I've tracked the hard fault to inside the llh_isr_handler within the cy_ble_stack_mdk_soc_cm0p.a library, so I'm hoping someone here can provide some insight.

The BLE component is set up to run on a single core on the CM0+ and everything works ok (can connect to BLE central, bond, save bonding information to emEEPROM) if I disable the CM4 by calling Cy_SysDisableCM4() in the CM0+ main function. However, if I enable the CM4 (after BLE stack is up, to avoid any flash contention with EEPROM), when I try to connect a BLE central, the hard fault appears. All of this happens when I am using the linker scripts that put this bootloadable application in the appropriate location to support DFU. However, if I compile the image as a standalone program (linker script changes so flash start for m0 = 0x10000000), I no longer get the hard fault and I can connect+bond without issue.

So, I'm having trouble explaining these things. If there was some contention between the M4 and M0, I don't understand why moving the image around would fix the issue. If the location in flash makes a difference, what setting to I need to change to make things work in the bootloadable application? Does anyone have insight into what could cause this issue?

Thanks,
Theo

[euggersh]

MichaelF_56​, we really need to get this answered.  Is anyone from Cypress monitoring this forum?  It's been over 24 hours.

[GeonaP_26]

ThBr_4364666​ MiRo_263836​

• As per shared call stack, Cy_SysLib_ProcessingFault is called from RTOSInit.c. Are you facing this issue in a normal project without RTOS? Also, did you try increasing the task stack size?
• Does this issue occur only when you are using low power modes?
• Flash write operation is allowed only in one of these CM4 states; CM4 is Active and initialized / CM4 is Off. As the entire BLE component is on CM0+, please call Cy_SysEnableCM4(CY_CORTEX_M4_APPL_ADDR) at the start of main_cm0p.c.
• Which DFU architecture is used at your end? Does both Apps use BLE CPU core as CM0+?
• Are you using Emulated EEPROM component? If yes, please disable UseBlockingWrite in Emulated EEPROM component configuration window.

Could you please share the project to review the linker script settings, project configurations and recreate the issue at our end?

[ThBr_4364666]

• As per shared call stack, Cy_SysLib_ProcessingFault is called from RTOSInit.c. Are you facing this issue in a normal project without RTOS? Also, did you try increasing the task stack size?
  • I don't have a similarly complicated project without an RTOS. I did try increasing the BLE task stack size to a few KB and it did not seem to help.
• Does this issue occur only when you are using low power modes?
  • Are you talking about the "Use BLE low power mode" in the BLE component or something else? I haven't tried disabling the BLE low power mode.
• Flash write operation is allowed only in one of these CM4 states; CM4 is Active and initialized / CM4 is Off. As the entire BLE component is on CM0+, please call Cy_SysEnableCM4(CY_CORTEX_M4_APPL_ADDR) at the start of main_cm0p.c.
  • If I call Cy_SysEnableCM4 at the start of main_cm0p.c, the M4 core becomes unresponsive when the BLE stack starts. What I currently do is call CySysDisableCM4() in main_cm0p.c and then call Cy_SysEnableCM4 after the BLE stack finishes start up.
• Which DFU architecture is used at your end? Does both Apps use BLE CPU core as CM0+?
  • The bootloader and bootloadable are separate, self contained images like in CE216767 with encryption and signing for the bootloadable. The bootloader has the BLE on the CM4, bootloadable has the BLE on CM0+.
• Are you using Emulated EEPROM component? If yes, please disable UseBlockingWrite in Emulated EEPROM component configuration window.
  • Yes, the project is set up to use non-blocking writes

For code access, I can't post it in a public forum, but I should be able to give you access via github if you sent me your github id.

[ThBr_4364666 · Accepted solution]

When digging through the .map files, I found that the bootloadable's RAM allocation for the m0+ and m4 cores were overlapping. It's unfortunate that nothing in the toolchain complained about that. When that bug was fixed, I no longer experience the hard fault in llh_isr_handler and I can call Cy_SysEnableCM4(...) in main_cm0p.c without issue.

I am still having a problem with saving bonding information in emEEPROM though. Cy_BLE_StoreBondingData() is returning CY_BLE_ERROR_FLASH_WRITE, so something in the set up is not quite right. I'll keep on digging.