Hi,
I'm using Segger Embedded Studio (with gcc naturally). The standard C++ exception handling doesn't work: exceptions are not caught by exception handler. Is there a way to enable normal C++ behaviour?
Thanks,
Daniel
Hi,
I'm using Segger Embedded Studio (with gcc naturally). The standard C++ exception handling doesn't work: exceptions are not caught by exception handler. Is there a way to enable normal C++ behaviour?
Thanks,
Daniel
Hello Daniel,
For questions regarding Segger Embedded Studio, I would recommend asking the Segger Forum e.g. https://forum.segger.com/index.php/Thread/4448-Have-to-import-cpp-files-to-run-code/
Similar questions regarding the nRF SDK and C++ usage have been asked before, have a look here and here.
Kind regards,
Øyvind
Øyvind,
Sorry but I don't get it - can you elaborate why these links are relevant to my question?
Best,
Daniel
Not directly connected to your question, but since you are asking in our forum I would like to inform you that Nordic Semiconductor doesn't have any official support for C++ in SES (or any other compiler) so you will have to do some of the error searching here yourself.
Kind regards,
Øyvind
Øyvind,
OK, C then: since unlike C++, C doesn't have a mechanism for systematic exception handling, can you recommend the Nordicsemi preferred way (in C) to recover from HW faults?
Best,
Daniel
Daniel,
The nRF SDK has built-in error handling, see HardFault handling library and Error module in the SDK v15.3 documentation. This tutorial is also a good read to learn about the error handling in nRF5 projects.
Hope this answers your question.
Kind regards,
Øyvind
Øyvind,
From browsing the links you sent it appears that there is a function HardFault_Handler which in turn calls HardFault_c_handler. Furthermore, I see that there is an assembly implementation of HardFault_Handler in \nRF5_SDK_15.3.0_59ac345\components\libraries\hardfault\nrf52\handler\hardfault_handler_gcc.c
My questions:
1. Do I need to compile this as part of my project?
2. Does implementing HardFault_c_handler interfere with softdevice?
3. What is the uint32_t * parameter passed to HardFault_c_handler?
Best,
Daniel
The Hard Fault handler is based on ARM 's own exception handler: https://developer.arm.com/docs/dui0553/latest/the-cortex-m4-processor/exception-model/exception-handlers and this handles all CPU specific faults that can occur, but should not. ARM describes these faults here: https://developer.arm.com/docs/dui0553/latest/the-cortex-m4-processor/fault-handling To learn more about the ARM Instruction set (Assembly) please see this link.
The Error Module handles application specific errors, it uses the app_error_fault_handler for handling application and SoftDevice errors and is the default in our SDK.
Daniel Reisfeld said:1. Do I need to compile this as part of my project?
No, you do not need to implement it, but we highly recommend it.
Daniel Reisfeld said:2. Does implementing HardFault_c_handler interfere with softdevice?
When certain unrecoverable errors occur within the application or SoftDevice, the fault handler will be called. This fault handler function is passed to the SoftDevice during initialization (sd_softdevice_enable())
HardFault should never happen; it might happen because of a code error, electromagnetic interference (EMI) near the device, or glitches on power lines. In this case, the microcontroller will hang in an endless loop until the next reset, unless a watchdog is used in the code.
Daniel Reisfeld said:3. What is the uint32_t * parameter passed to HardFault_c_handler?
This is the program stack pointer address, used in the HardFault_C_handler to indicate what caused the error:
[0] = "The processor has attempted to execute an undefined instruction",
[1] = "The processor attempted a load or store at a location that does not permit the operation",
[2] = NULL,
[3] = "Unstack for an exception return has caused one or more access violations",
[4] = "Stacking for an exception entry has caused one or more access violations",
[5] = "A MemManage fault occurred during floating-point lazy state preservation",
[6] = NULL,
[7] = NULL,
[8] = "Instruction bus error",
[9] = "Data bus error (PC value stacked for the exception return points to the instruction that caused the fault)",
[10] = "Data bus error (return address in the stack frame is not related to the instruction that caused the error)",
[11] = "Unstack for an exception return has caused one or more BusFaults",
[12] = "Stacking for an exception entry has caused one or more BusFaults",
[13] = "A bus fault occurred during floating-point lazy state preservation",
[14] = NULL,
[15] = NULL,
[16] = "The processor has attempted to execute an undefined instruction",
[17] = "The processor has attempted to execute an instruction that makes illegal use of the EPSR",
[18] = "The processor has attempted an illegal load of EXC_RETURN to the PC, as a result of an invalid context, or an invalid EXC_RETURN value",
[19] = "The processor has attempted to access a coprocessor",
[20] = NULL,
[21] = NULL,
[22] = NULL,
[23] = NULL,
[24] = "The processor has made an unaligned memory access",
[25] = "The processor has executed an SDIV or UDIV instruction with a divisor of 0",
The Hard Fault handler is based on ARM 's own exception handler: https://developer.arm.com/docs/dui0553/latest/the-cortex-m4-processor/exception-model/exception-handlers and this handles all CPU specific faults that can occur, but should not. ARM describes these faults here: https://developer.arm.com/docs/dui0553/latest/the-cortex-m4-processor/fault-handling To learn more about the ARM Instruction set (Assembly) please see this link.
The Error Module handles application specific errors, it uses the app_error_fault_handler for handling application and SoftDevice errors and is the default in our SDK.
Daniel Reisfeld said:1. Do I need to compile this as part of my project?
No, you do not need to implement it, but we highly recommend it.
Daniel Reisfeld said:2. Does implementing HardFault_c_handler interfere with softdevice?
When certain unrecoverable errors occur within the application or SoftDevice, the fault handler will be called. This fault handler function is passed to the SoftDevice during initialization (sd_softdevice_enable())
HardFault should never happen; it might happen because of a code error, electromagnetic interference (EMI) near the device, or glitches on power lines. In this case, the microcontroller will hang in an endless loop until the next reset, unless a watchdog is used in the code.
Daniel Reisfeld said:3. What is the uint32_t * parameter passed to HardFault_c_handler?
This is the program stack pointer address, used in the HardFault_C_handler to indicate what caused the error:
[0] = "The processor has attempted to execute an undefined instruction",
[1] = "The processor attempted a load or store at a location that does not permit the operation",
[2] = NULL,
[3] = "Unstack for an exception return has caused one or more access violations",
[4] = "Stacking for an exception entry has caused one or more access violations",
[5] = "A MemManage fault occurred during floating-point lazy state preservation",
[6] = NULL,
[7] = NULL,
[8] = "Instruction bus error",
[9] = "Data bus error (PC value stacked for the exception return points to the instruction that caused the fault)",
[10] = "Data bus error (return address in the stack frame is not related to the instruction that caused the error)",
[11] = "Unstack for an exception return has caused one or more BusFaults",
[12] = "Stacking for an exception entry has caused one or more BusFaults",
[13] = "A bus fault occurred during floating-point lazy state preservation",
[14] = NULL,
[15] = NULL,
[16] = "The processor has attempted to execute an undefined instruction",
[17] = "The processor has attempted to execute an instruction that makes illegal use of the EPSR",
[18] = "The processor has attempted an illegal load of EXC_RETURN to the PC, as a result of an invalid context, or an invalid EXC_RETURN value",
[19] = "The processor has attempted to access a coprocessor",
[20] = NULL,
[21] = NULL,
[22] = NULL,
[23] = NULL,
[24] = "The processor has made an unaligned memory access",
[25] = "The processor has executed an SDIV or UDIV instruction with a divisor of 0",
Øyvind,
Thanks for your most helpful answer,
Daniel