Data logging programme hangs if DAPLink does not have micro:bit specific features

[microbit-carlos]

This MakeCode programme hangs at the data logging block, so the micro:bit only shows the sad face image, it never reaches the beating heart:

microbit-dl-simple.hex.zip

All micro:bits from factory include the I2C functionality, but if somebody builds DAPLink from source they can build the version without it (technically, this is the only version merged in DAPLink upstream right now, the V2 functionality is still in a PR), or users could be using J-Link instead:
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/bbc-microbit-j-link-upgrade/

This DAPLink image can be used for testing:
kl27z_microbit_if.hex.zip

[JohnVidler]

Ideally we should panic rather than hang if the i2c comms for logging data are not working.

Some kind of sensible default timeout should be set in CODAL to stop this a forever-wait.

[microbit-carlos]

The latest CODAL also does an I2C transaction on uBit.init() (or thereabouts), so for non-DAPLink users (right now, that's only J-Link users I think), that has the potential to affect all micro:bit programmes, and not only those using DAPLink-I2C-specific features.

[JohnVidler]

May be related to #191 once we implement the panic code.

[microbit-carlos]

We need to consider that MAINTENACE mode in DAPLink doesn't have I2C features,.

So, if we panic when we fail to establish I2C comms, then a micro:bit programme would panic in MAINTENACE mode during uBit.ini(), which we don't want, as it should only panic at the point the user is using DAPLink I2C specific features like datalogging:

codal-microbit-v2/model/MicroBit.cpp

Lines 219 to 221 in b587d9c

	#if CONFIG_ENABLED(DEVICE_BLE) && ( CONFIG_ENABLED(MICROBIT_BLE_PAIRING_MODE) || CONFIG_ENABLED(MICROBIT_BLE_ENABLED))
	MicroBitVersion version = power.getVersion();
	#endif

In this case we would either have:
a) Bubble up error codes and figure out at what layers to panic
- In this example it cannot panic inside power.getVersion(), but that is a user facing uBit API.
b) Remove this board ID check from uBit.init(), and panic at the layer that first detects DAPLink is not responding to I2C.
- #208
c) Other?

[martinwork]

Couldn't the log data call timeout, and not log the data, From memory, it may be that it isn't actually hanging, but the timeout becomes very long (say 20 * 20 * 10s) when I2C is not responding.

[JohnVidler]

After some discussion, we've decided to handle this by only attempting calls which will panic when we actually need to access the flash rather than querying version like so:

codal-microbit-v2/model/MicroBit.cpp

Line 253 in b587d9c

bleManager.init( ManagedString( microbit_friendly_name()), getSerial(), messageBus, storage, true, version.board);

on startup.

This way we only panic when we actually do something with DAPLink, with an exception for when we have the ERASE FLASH flag set in codal config, but DAPLink is unreachable, we should NOT panic, otherwise setting that config will immediately halt the board.