Panic Codes don't match the micro:bit V1

[microbit-carlos]

V1 defined in the DAL repo: https://github.com/lancaster-university/microbit-dal/blob/602153e9199c28c08fd2561ce7b43bf64e9e7394/inc/core/ErrorNo.h#L72-L89

enum PanicCode{
    // PANIC Codes. These are not return codes, but are terminal conditions.
    // These induce a panic operation, where all code stops executing, and a panic state is
    // entered where the panic code is diplayed.

    // Out out memory error. Heap storage was requested, but is not available.
    MICROBIT_OOM = 20,

    // Corruption detected in the micro:bit heap space
    MICROBIT_HEAP_ERROR = 30,

    // Dereference of a NULL pointer through the ManagedType class,
    MICROBIT_NULL_DEREFERENCE = 40,

    // A requested hardware peripheral could not be found,
    MICROBIT_HARDWARE_UNAVAILABLE_ACC = 50,
    MICROBIT_HARDWARE_UNAVAILABLE_MAG = 51,
};

V2 might be using the values from the codal-core repo:
https://github.com/lancaster-university/codal-core/blob/befa2c51b3595ca0d44e1bc5daad0531974b77e7/inc/core/ErrorNo.h#L80-L105

enum PanicCode{
    // PANIC Codes. These are not return codes, but are terminal conditions.
    // These induce a panic operation, where all code stops executing, and a panic state is
    // entered where the panic code is diplayed.

    // Out out memory error. Heap storage was requested, but is not available.
    DEVICE_OOM = 20,

    // Corruption detected in the codal device heap space
    DEVICE_HEAP_ERROR = 30,

    // Dereference of a NULL pointer through the ManagedType class,
    DEVICE_NULL_DEREFERENCE = 40,

    // Non-recoverable error in USB driver
    DEVICE_USB_ERROR = 50,

    // Non-recoverable error in the JACDAC stack
    DEVICE_JACDAC_ERROR = 60,

    // CPU SDK faults
    DEVICE_CPU_SDK = 70,

    // hardware incorrect configuration
    DEVICE_HARDWARE_CONFIGURATION_ERROR = 90,
};

[JohnVidler]

@finneyj Do you have some comment on this?

I'm inclined to update these to match the web documentation on the help pages and the original DAL messages wherever possible/appropriate... was there a reason that these diverged, or is it just error-code-rot?

[scc110-2022]

When we generalized microbit-dal into codal-core, we dropped a lot of device specific content for obvious reasons, with the concept that additional constants could be layered back on the the device level repos (codal-microbit-v2 etc). It looks a bit like we did that, then the USB error sneaked into the gap that was left in codal-core...

Suggest we generalize 50 to be "hardware error", then map in the V1 codes to that? (especially seeing as v2 boards have combined acc/mag sensors anyway)? Perhaps we could also 51 as I2C failure, 52 for USB?

What thinks @microbit-carlos @JohnVidler

[finneyj]

I really must remember to sign out of my education account :)

[JohnVidler]

Check that panic codes have no hard coded constants in their classes for speicific devices, otherwise check the panic codes align.

[JohnVidler]

See the above merged PRs for how this has been addressed, but essentially I've now repurposed the 50-59 panic range to be board/implementation specific for peripheral device failures.

In the case of the Micro:bit v2 we now have this enum:

enum MicroBitPanic {
    // Accelerometer unable proceed (hardware i/o failure)
    ACCELEROMETER_ERROR = PanicCode::DEVICE_PERIPHERAL_ERROR + 1, // Aka. Panic 51

    // Compass unable to proceed (hardware i/o failure)
    COMPASS_ERROR = PanicCode::DEVICE_PERIPHERAL_ERROR + 2        // Aka. Panic 52
};

in MicroBitError.h which lets us define Micro:bit specific peripheral failure codes.

Closing as complete, but happy to address issues that may arise from this in new issues filed with details of the boards and errors it causes (although I personally expect that this will cause negligable problem cases)

[microbit-carlos]

Reopening as we need the panic codes to be 50/51, not 51/52.

This also needs to be fixed: #216 (comment)

[JohnVidler]

Marking as complete, as I've moved these back to 50/51.

The comment @microbit-carlos mentions will be tracked in its own issue.