C++ exception

RE: C++ exception

Daniel Reisfeld — Sat, 06 Apr 2019 07:22:11 GMT

Øyvind,

Thanks for your most helpful answer,

Daniel

RE: C++ exception

Øyvind — Fri, 05 Apr 2019 12:05:04 GMT

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.

[quote user="danielReisfeld"]1. Do I need to compile this as part of my project?[/quote]

No, you do not need to implement it, but we highly recommend it.

[quote user="danielReisfeld"]2. Does implementing HardFault_c_handler interfere with softdevice?[/quote]

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.

[quote user="danielReisfeld"]3. What is the uint32_t * parameter passed to HardFault_c_handler?[/quote]

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",

Kind regards,
Øyvind

RE: C++ exception

Nguyen Hoan Hoang — Thu, 04 Apr 2019 15:59:35 GMT

I don't know about SES but it might disabled it by default. The GCC flag to disable exceptions is -fno-exceptions. Look to see if it compiles with this flag.

RE: C++ exception

Daniel Reisfeld — Thu, 04 Apr 2019 14:15:23 GMT

Ø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

RE: C++ exception

Øyvind — Thu, 04 Apr 2019 13:04:58 GMT

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

RE: C++ exception

Daniel Reisfeld — Thu, 04 Apr 2019 12:19:13 GMT

Ø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

RE: C++ exception

Øyvind — Thu, 04 Apr 2019 12:06:51 GMT

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

RE: C++ exception

Daniel Reisfeld — Thu, 04 Apr 2019 11:51:53 GMT

Øyvind,

Sorry but I don't get it - can you elaborate why these links are relevant to my question?

Best,

Daniel

RE: C++ exception

Øyvind — Thu, 04 Apr 2019 11:39:42 GMT

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