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

lancaster-university / codal-microbit-v2

CODAL target for the micro:bit v2.x series of devices

MIT License

42 stars 51 forks source link

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

Open microbit-carlos opened 3 years ago

microbit-carlos commented 3 years ago

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:

Screenshot2021_07_20_110233

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

microbit-carlos commented 2 years ago

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: https://github.com/lancaster-university/codal-microbit-v2/blob/b587d9c26f5e93a2054ba8b36a6cdcc27b234419/model/MicroBit.cpp#L219-L221

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.
https://github.com/lancaster-university/codal-microbit-v2/issues/208 c) Other?

martinwork commented 2 years ago

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 commented 1 year ago

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: https://github.com/lancaster-university/codal-microbit-v2/blob/b587d9c26f5e93a2054ba8b36a6cdcc27b234419/model/MicroBit.cpp#L253 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.