search

WildernessLabs / Meadow_Issues

Public repo for bugs and issues with Meadow
15 stars 0 forks source link

For debugging Meadow.OS is sending the Concluded message too early #771

Closed Peter-Moody closed 1 month ago

Peter-Moody commented 2 months ago

Describe the bug The HCOM/Meadow code required to initiate the VS debugging session uses the follow steps

Remote debugging startup sequence:

  1. CLI sends a message HCOM_MDOW_REQUEST_MONO_START_DBG_SESSION to HCOM to initiate the debugging session.
  2. HCOM sets a bit HCOM_BBREG_MONO_DEBUGGING_START_BIT in a battery backed register (BBR).
  3. HCOM restarts Meadow (my assumption is the Mono needs to be restarted in order to run in the remote debugging mode).
  4. During the Meadow restart HCOM checks the BBR flag. If it's NOT set, it exits.
  5. If it is set, HCOM starts a thread for handling remote debugging. After starting the thread the startup thread exits.
  6. When this newly created thread runs it handles a few chores such as opening the Mono socket and preparing to accept the Mono connection request. All of which will only happen after Mono has started.
  7. Once connected to Mono this thread blocks waiting for binary, debugging data from Mono. As this binary data is received this thread uses HCOM to forward the debug data to CLI.

Background: For every request CLI sends to Meadow, HCOM responses with a Concluded message once the request has been fully processed. This was done to add a simple handshake, without actually modifying protocol. For those requests that result in a Meadow restart, the Concluded message is sent immediately after HCOM has restarted.

Problem: Because HCOM sends the Concluded message, as soon as HCOM code begins execution, CLI can immediately begin sending binary debugging data, even though Mono may not have started. The remote debugging Concluded message should not be sent to CLI until remote debugging is fully operational. This, of course, assumes that that CLIv2, waits for Concluded messages before resuming/completing the requests it has initiated.

Additional information: Almost 2 years ago Mark added a delay, which postpones the transmission of the first message to CLI. Alexis increased this delay from 2 seconds to 4 seconds a few months ago. This delay has no effect on when CLI begins sending binary debug data to Meadow. It delays the sending of the first debugging message received from Mono. But, this is after CLI has sent binary debug data to HCOM and on to Mono, telling Mono what to do (e.g. run, change a variable, set a break point...).

To Reproduce Attempt to debug a MeadowApp, notice that it usually takes several attempts to be successful starting the process.

Expected behavior Debugging a MeadowApp should just work every time without multiple attempts.

Developer tools (please complete the following information as best as you can):

Meadow (please complete the following information as best as you can): Most of these values can be found by running meadow device info using the Meadow CLI.

Peter-Moody commented 2 months ago

Updated Issue based on new information discovered recently.

alexischr commented 1 month ago

I think neither the title nor the description of the issue are fully accurate to our understanding anymore. @Peter-Moody let's close this please, or adjust it so that it is true if there is anything still useful/informative in the description.

Peter-Moody commented 1 month ago

I agree. This description and title are not accurate.