Some insight into Recovery mode

[crowbarmaster]

Hello good folks!

I've been trying to work the best way to work detection of recovery into the UNO app. I have things working to some extent:

Messenger_creation_337AA945-7EBE-439D-A41D-9CF242945106.jpeg

But it's clunky, the wait for a reply takes a lot of extra time, enough to where this doesn't work without several seconds added to the timeout. I'd call that a loss, as that creates uncertainty.

I have noticed that almost immediately after failing the OSID check, the PCM begins to spam command A2 back.

I've scoured my logs of every successful communications attempt I have, and I don't see where that has any use on a functional PCM. I can actually see in MockPCM that this is labeled as "Programming Prompt". Could this be used to detect recovery instead? In reality it would solve all issues and the loop can retain a low timeout. We will be expecting the OSID to fail in recovery mode, so we will either need to increase the timeout by just a mere couple of seconds, or make the OSID test fail faster. I'm also going out on a limb here, but I'm going to assume under the influence of a live kernel, this spamming wouldn't happen either. I only have experience with P01 right now, so I'll need to know if this is unique to the P01 or a constant between units.

I have connections to the yard down the road from me, I'm going to try to talk him into grabbing a bulk of different ECUs to play with for the good of humanity He won't be that nice, but I definitely will walk out with as many as I can for under a ben and have plenty to work with.

If this isn't a viable option, I have other ideas around this, but I'll hold off for the moment.

Thank you!

[antus]

Yep the bootloader spams out A2 if it fails checks at start up. It could be looked for first. The nexr byte tells you if the bootloader is damaged, it failed the OS check or the Calibration check. All 3 cycle at different speeds, and different PCMs are slightly different (some recovery times out and stops, others dont). Scantools are a real trouble because theyre so slow when the fastest A2 comes so fast, and the A2s are spamming out so dont fit the 1 transmit then 1 receive pattern tjat protocol is designed for. It works a lot better on other tools that can independantly send and receive.

[crowbarmaster]

Okay, were getting somewhere then. Let me rip out the OBDLink and get to some testing... I think I might have some suggestions that could make this possible. I'm a proof of concept kind of guy, so give me a bit and let me try this out. I had my MX+ picking up those messages without a problem, and I believe that might have something to do with the way I'm handling the incoming data.

I'll post my finding soon!

[crowbarmaster]

Okay, Check this out!

This testing is done with my OBDLink MX+ under native BT. If there is something slower yet that should be tested, perhaps we could get this to someone that could assist. I could also do a variant based on regular ELM commands.

Firstly, I needed a new feature in the Elm implimentation that goes like so:

Screenshot 2026-04-01 181055.png

Then a way to check for broadcasted commands:

Screenshot 2026-04-01 181943.png

As you can see, it found the message I was after, and passed the test. The whole process happens quickly,

For reference sake, it's being called in the polling loop like so:

Screenshot 2026-04-01 182456.png

I wrote a variation for the OBDX that passes too:

Screenshot 2026-04-01 191549.png

I'll look into add this to the J devices and get some testing there too. I can write something for AVT I'm sure, but I have no way to test that.

Let me know if I maybe missed something important here!

Update: I made a few adjustments, and have a normal looking polling loop under good programming. Things are looking good!

[antus]

Sounds good. I have an AVT and can test that if you get a branch somewhere. I also have the allpro though that hasnt seen the light of day for a long time and I think NSFW might be the only one using one.