A "Hard Fault" exception is called when you try to
Execute code from non-existent or non-exec memory
Accessing non-existent memory
There are some more, see (excerpt from "Cortex M0 Devices Generic User Guide)
2.4 Fault handling
Faults are a subset of exceptions, see Exception model on page 2-19. All faults result in
the HardFault exception being taken or cause lockup if they occur in the NMI or
HardFault handler. The faults are:
• execution of an SVC instruction at a priority equal or higher than SVCall
• execution of a BKPT instruction without a debugger attached
• a system-generated bus error on a load or store
• execution of an instruction from an XN memory address
• execution of an instruction from a location for which the system generates a bus
• a system-generated bus error on a vector fetch
• execution of an Undefined instruction
• execution of an instruction when not in Thumb-State as a result of the T-bit being
previously cleared to 0
• an attempted load or store to an unaligned address.
So I suppose something is wrong with your memory allocation or wth the bootloader's addresses.
Don't put the device in debug mode while debugging a project with Bootloader functionality. The switching between bootloader and Bootloadable project happens followed by a software reset and the debugger will disconnected on reset.
Also, the Bootloadable component manages the placement of the application image in the FLASH Area with respect to Bootloader image and hence on disabling the Bootloadable component and debugging will result in Hard fault.
Please use UART debug logs for debugging the OTA projects.
JoMe_264151 I read that and it's a pretty long list which is why I need to use the debugger. Since the fault is coming from CyBle_ProcessEvents() there is no source code, so I am asking what to do next The setup for the BLE is from the example, so it should work fine.
GyanC_36 I'm painfully aware of the OTA debug limitation, but to debug in, I attached after start ,which I'm being told is fine. I also did not disable the bootloader component or the code sharing, only the PWM. So I don't see how your advice applies to this problem.
Hello MiMi_1891471 ,
Could you please let us know the steps to reproduce the issue?
Hope you have Flashed the Launcher -> Stack -> Application Project to the PSoC BLE device with appropriate dependencies and you know how the switching happens between all of the projects on device program Cycle/ Power Cycle/ Reset/ On manual switch between the Application and Bootloader.
Please let us know the steps so that we can verify the cause of problem.
Sorry for the slow reply, as I mentioned in my original post "The PWM page can be disabled and enabled to show the issue follows the components and supporting code. " So you should be able to recreate easily using 042 Dev board with 224110 module installed. The Bootloadable app runs fine with the PWM page disabled, but if you enable it, CyBLE_Process_Events will hard fault, and I cannot figure out why.
Since then, I had suspected interrupt issues, but I have actually tried another way where my interrupts were all removed and systimers used instead, and I get the sameresult. So now really the only thing new is PWM without interrupts unless the systimer interrupts themselves are the problem. That attempt is attached. You can't disable the page in this one, but it waits with red LED lit until you press S2 so that you can attach the debugger early in main.c. Then step through and see where it hard faults, always on CYBLE_ProcessEvents().
I'd really appreciate some help, I really have no visibility into the BLE subsystem to understand what is wrong. I'm just using the example code with what should be easy modifications.
BootloadableDebug.Bundle01.zip 12.7 MB
1 of 1 people found this helpful
Since you are using system Low Power Modes and in DeepSleep mode neither PWM block nor systick timer ( uses IMO for clock source) are available/will not function.
Either do not use Low Power code or use WDT timer.
With Low Power code disabled , the project ( attached here ) is working fine.