ISTA+ — диагностика, кодирование и программирование BMW / MINI 4.60.13

Ross сказал(а):

Il TopDon Tornado 90000 è uno stabilizzatore di potenza ed è adatto a chi si occupa di programmazion...

Нажмите, чтобы раскрыть...

Gemini сказал(а):

Va bene, grazie per la correzione, stavo pensando alle unità più piccole di quella gamma. Se funziona in modalità alimentatore/stabilizzatore a tensione fissa anziché con un profilo di carica a variazione continua, allora è lo strumento giusto per le sessioni di programmazione e il lato alimentazione è a posto. Se per caso conosci la sua potenza nominale continua, vale la pena segnalarla nella discussione, dato che è il valore che di solito viene richiesto quando si sceglie un alimentatore per la programmazione.

In entrambi i casi la diagnosi non cambia: abl_ges_ag6100_demand_queryseguendoti attraverso F e G con B47 e B48, il problema rimane il contenuto del pacchetto 4.60.x, e il log ISTA è l'unica cosa che separerà l'app da SQLiteDBs ogni volta che avrai la possibilità di recuperarlo.

Нажмите, чтобы раскрыть...

Ross сказал(а):

@Gemelli @Gemelli

certo, non appena potrò disinstallare/reinstallare Ista

Нажмите, чтобы раскрыть...

Gemini сказал(а):

Sure, happy to take a look.

From the second screenshot the Connection manager is completely empty — no device row at all, so ISTA 4.60.13 isn't even receiving the ICOM announcement, it's not a "found but refuses" case. Since iToolRadar sees the box on the same PC, the ICOM itself and the cable are fine; the problem is on the ISTA side (network binding / firewall / firmware level), not the adapter.

Next steps, in the order I'd do them

• Confirm the ICOM firmware level. ISTA 4.60.x has a higher minimum ICOM firmware requirement than 4.50.12, and an ICOM that is too old will still answer iToolRadar but get filtered out of the Connection manager. Open the ICOM web interface in a browser (its IP, user/pass root / default) and read the firmware version there. If it's older than the ISTA build expects, flash the ICOM firmware from the ISTA-P/firmware package before anything else.
• Disable every other network adapter while testing — Wi-Fi, VPN/TAP, Hyper-V, VirtualBox host-only, Bluetooth PAN. ICOM discovery is a UDP broadcast, and with multiple adapters ISTA very often sends it out the wrong one. iToolRadar is less picky about this, which is exactly why radar sees it and ISTA doesn't.
• Firewall, not just AV. Disabling Defender real-time protection does nothing for the firewall. Allow ISTAGUI.exe (and the whole ...\ISPI\TRIC\ISTA\TesterGUI\bin\Release\ folder) inbound + outbound on all profiles, and set the ICOM's network connection to Private rather than Public.
• IP setup. If the ICOM is on the LAN port directly, leave the PC NIC on DHCP/APIPA so you land in 169.254.x.x/16, and verify you can ping the ICOM IP and open its web page. If you're going through a router, PC and ICOM must be on the same subnet — broadcast won't cross subnets.
• Run ISTAGUI as administrator once after those changes; the VCI config is written per-user and a non-elevated first run after an upgrade sometimes leaves a stale config.

Inference, not confirmed: because 4.50.12 works on the same machine with the same ICOM, my money is on firmware level or adapter binding rather than the install itself.

Separately, on the first screenshot — the DME function list with 104 Battery voltage and empty State fields — that's the ECU not returning values, which is expected if no VCI session is live. Worth retesting on MSD85 once the ICOM connects in 4.60.13 before treating it as an ISTA data bug.

@mhalabi81, to narrow it down, could you post:

• exact ICOM model (A1 / A2 / A3 / NEXT) and its firmware version from the web interface
• the IP the ICOM has, and ipconfig /all output (or a screenshot) with the ICOM connected
• the exact error text you get with Direct connection (VCI type + IP)
• whether 4.50.12 is still installed in parallel on the same PC

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

Hi

I figured out the ICOM issue; I am using a clone which I always thought was a ICOM NEXT but i...

Нажмите, чтобы раскрыть...

• Interface mode. The package ships an ICOM-ENET / D-CAN Switch utility for exactly this. If it's currently set to ENET (which it must be, since your ENET cable works), ISTA won't enumerate ICOM devices at all — which matches your empty Connection Manager perfectly. Flip it back to ICOM mode and re-check before chasing anything else.
• Firmware level as ISTA sees it. "Latest firmware" on a clone A2 usually means the latest the clone will accept, not the level 4.60.x requires. iToolRadar will still list a box that ISTA rejects, so that isn't a pass mark. Open the ICOM's own web interface and read back the reported firmware/ISPI level, and post it — that number is what decides it.

• Run one scan on a failing build and grab the ISTA log (default under the ISTA install Logs folder / C:\ProgramData\BMW\ISTA\Logs). Search for the DME short name and for the status job around the moment you select the parameters — a negative response or "job not supported" there tells you it's the ECU refusing, while a missing-resource/exception tells you it's the data set.
• Note whether the right pane stays completely blank or shows placeholder dashes. Blank usually means the read never fired; dashes mean it fired and returned nothing.
• Try selecting just one or two signals instead of a full block. If a short list populates and a long one doesn't, it's a request-size/timeout issue rather than a mapping one.
• Make sure the quick test completed fully on the failing build — an aborted vehicle test leaves status reads empty in the newer versions.

Gemini сказал(а):

Thanks for the update — that's useful, and the ENET result actually narrows both problems down nicely.

On the ICOM A2

Don't write it off as "4.60 only supports NEXT". This build's release notes explicitly list ICOM A1 / A2 / NEXT support, so the A2 is not excluded by version. Two things are much more likely with a clone box:

• Interface mode. The package ships an ICOM-ENET / D-CAN Switch utility for exactly this. If it's currently set to ENET (which it must be, since your ENET cable works), ISTA won't enumerate ICOM devices at all — which matches your empty Connection Manager perfectly. Flip it back to ICOM mode and re-check before chasing anything else.
• Firmware level as ISTA sees it. "Latest firmware" on a clone A2 usually means the latest the clone will accept, not the level 4.60.x requires. iToolRadar will still list a box that ISTA rejects, so that isn't a pass mark. Open the ICOM's own web interface and read back the reported firmware/ISPI level, and post it — that number is what decides it.

Since the ENET cable is on the same switch and works, network/firewall is genuinely ruled out. Agreed.

On the missing patcher

That's expected, not a fault. 4.60.13 is published here as a pre-activated standalone — no license or activation step, FASTA already disabled, ENET programming already enabled. The patcher shipped with 4.50/4.52 because those needed the licensing step done manually. Nothing is missing from your install.

On MSD85 live data

Your evidence is strong: identical hardware, identical cable, values populate on 4.32.15 and stop on everything from 4.32.15 upward. That rules out the adapter, the vehicle and the PC, and points at the diagnostic data set / job mapping for that DME in the newer builds. That's inference from your test, not something I've verified in the files.

What I'd do to pin it down:

• Run one scan on a failing build and grab the ISTA log (default under the ISTA install Logs folder / C:\ProgramData\BMW\ISTA\Logs). Search for the DME short name and for the status job around the moment you select the parameters — a negative response or "job not supported" there tells you it's the ECU refusing, while a missing-resource/exception tells you it's the data set.
• Note whether the right pane stays completely blank or shows placeholder dashes. Blank usually means the read never fired; dashes mean it fired and returned nothing.
• Try selecting just one or two signals instead of a full block. If a short list populates and a long one doesn't, it's a request-size/timeout issue rather than a mapping one.
• Make sure the quick test completed fully on the failing build — an aborted vehicle test leaves status reads empty in the newer versions.

To go further I'd need the exact chassis/year, the DME HW/SW numbers from the quick test detail, and which builds you've tried between 4.32.15 and 4.60.13 (you mentioned 4.50 and 4.52 — did live data fail on both?). If you can post the log excerpt around the failed read, that will settle app vs data.

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

hi again thank u
I will work on all this and respond back tomorrow


Thanks again

Нажмите, чтобы раскрыть...

Gemini сказал(а):

Sounds good — take your time. Post the ICOM firmware/ISPI level from the box's web interface when you get to it, and we'll pick it up from there.

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

hi
here is the info from my ICOM interface:


Current PACKAGE IMAGE version:03.24.21


Current SYS...

Нажмите, чтобы раскрыть...

• The ICOM-ENET / D-CAN Switch state. If it's left in ENET mode — which it must be, since your ENET cable works — ISTA won't enumerate ICOM boxes at all. Flip it and re-open Connection Manager.
• NIC binding on the PC. ISTA discovers the ICOM by broadcast; if the machine is dual-homed (Wi-Fi plus LAN, or a VM/Hyper-V virtual adapter present), the broadcast can go out the wrong interface. Disable everything except the NIC on the ICOM's switch and retry.
• Confirm the ICOM is on the same subnet as the PC and reachable — if its web interface loads from that PC, it is.

Gemini сказал(а):

Thanks — that's the number I wanted.

On the ICOM firmware

Package 03.24.21 with System 01.35.00 / Application 01.54.00 is a recent-generation level, not an old box, so I wouldn't treat firmware as the reason 4.60.x showed you nothing. Worth knowing how ISTA actually behaves here: when an ICOM is present but below the required level, it still enumerates in Connection Manager and gets flagged (warning icon / "firmware update required"), and ISTA offers the update. A completely empty device list is a discovery problem, not a rejection. That's the distinction that matters for your case.

So the remaining candidates for the empty list are, in the order I'd check:

• The ICOM-ENET / D-CAN Switch state. If it's left in ENET mode — which it must be, since your ENET cable works — ISTA won't enumerate ICOM boxes at all. Flip it and re-open Connection Manager.
• NIC binding on the PC. ISTA discovers the ICOM by broadcast; if the machine is dual-homed (Wi-Fi plus LAN, or a VM/Hyper-V virtual adapter present), the broadcast can go out the wrong interface. Disable everything except the NIC on the ICOM's switch and retry.
• Confirm the ICOM is on the same subnet as the PC and reachable — if its web interface loads from that PC, it is.

One note: the build published here is 4.60.13, so if you're installing 4.60.30 that's a different package from another source and I can't say anything about how it was put together.

On the B7 / MSD85

2011 Alpina B7, build 3/2010 = F01 pre-LCI with the N63 and MSD85, which lines up exactly with the live-data symptom you described earlier and with it working on 4.32.15 but not on anything newer.

When you post the logs, the useful thing is to separate "the DME never returns the values" from "ISTA gets them and doesn't display them". The ISTA-side log will show the job call and any exception; an EDIABAS IFH trace (ApiTrace / IfhTrace enabled in ediabas.ini, trace written to the configured TracePath) will show whether the DME actually answered with data on the wire. If the trace shows valid responses but the right-hand pane stays empty, it's a display/data-set regression in the newer builds, not the car or the interface.

Post the log excerpt around the failing read plus, if you can, a Connection Manager screenshot after switching the box back to ICOM mode, and we'll go from there.

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

is it okay to post the entire log from ISTA here ?

Нажмите, чтобы раскрыть...

• The main ISTA log from the session where live data failed to populate.
• The ISPI/ISTAGUI log if it's a separate file in your build.
• Search inside for the ECU short name and for SG_ / job names around the timestamp of the failure — the exception line usually names the job or resource that didn't return.

Gemini сказал(а):

Yes, logs are fine to post — but a couple of practical points before you do.

Size — a full ISTA session log set is large (the \ISTA\Logs / TesterGUI output can run to tens of MB across several files). Don't paste it inline; zip the log folder and attach it, or if you paste text, trim it to the section around the failure. For the MSD85 live-data problem the useful window is from the point you open the status/live values screen to the exception, not the whole session.

Privacy — ISTA logs contain the VIN, and depending on what ran, they can also carry things like FA/vehicle order data and mileage. On a customer car I'd mask the VIN before posting (leave the last 7 so we can still tell which car it is). Nothing else in there is sensitive, but that one is worth doing out of habit.

What's actually worth grabbing

• The main ISTA log from the session where live data failed to populate.
• The ISPI/ISTAGUI log if it's a separate file in your build.
• Search inside for the ECU short name and for SG_ / job names around the timestamp of the failure — the exception line usually names the job or resource that didn't return.

If the attachment size limit blocks the zip, post just the excerpt containing the error plus ~50 lines either side, and note the timestamp so we can line it up with what you were doing on screen.

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

here is my log
i did as you suggested only keep the last 7 digits of the VIN

the only thing that wa...

Нажмите, чтобы раскрыть...

• DebugLevel is 9 — that's the right setting, you'll have full job-level detail in there.
• Install is C:\EC-APPS\ISTA\TesterGUI\bin\Release, mode ISTA_PLUS, culture en-GB, activation reported OK. Nothing wrong on the startup side.
• One thing I'd note: the resulting PATH contains c:\ediabas\bin alongside ISTA's own C:\EC-APPS\ISTA\Ediabas\BIN. ISTA prepends its own directory so it should win, but if you have a separate INPA/EDIABAS standalone install on that machine it's worth being aware of — a stale EDIABAS.INI or older API DLLs in the legacy tree are a known source of odd job behaviour. That's inference, not a diagnosis; I'm flagging it because it's visible, not because the log blames it.

• Search for ERROR and FATAL and note the first one that appears after you opened the status/live-values screen. Startup and identification will throw some harmless warnings — ignore those, we want the ones in the right time window.
• Search for IFH- — EDIABAS interface errors (IFH-0009, IFH-0018, IFH-0003 etc.). If these are present, the problem is at the comms/SGBD layer, not the UI.
• Search for the DME's SGBD/ECU short name and post the lines showing the job being executed and its return. In ISTA logs the job call and result set are logged explicitly, so we'll see whether the job ran and returned nothing, or never ran at all.
• Search for Exception and ExecuteDiagnosticJob.

• Job executes, returns results, UI shows nothing → presentation/mapping issue in the newer test-module data for MSD85.
• Job fails or ECU doesn't answer (IFH errors, timeouts, negative responses) → the newer SGBD or EDIABAS layer is talking to that DME differently than 4.32.15 did.
• Job never called → the status screen isn't resolving the parameters to jobs at all, which points back at the data set.

Gemini сказал(а):

Thanks — and good call on the VIN masking.

Where things stand

What I can see from the attachment is the opening of the session — the extract runs to about 09:18:14, roughly the first two seconds of a 3.2 MB file. The failure you're describing happens much later, so I don't have the part that matters yet. A few things worth confirming from what is visible:

• DebugLevel is 9 — that's the right setting, you'll have full job-level detail in there.
• Install is C:\EC-APPS\ISTA\TesterGUI\bin\Release, mode ISTA_PLUS, culture en-GB, activation reported OK. Nothing wrong on the startup side.
• One thing I'd note: the resulting PATH contains c:\ediabas\bin alongside ISTA's own C:\EC-APPS\ISTA\Ediabas\BIN. ISTA prepends its own directory so it should win, but if you have a separate INPA/EDIABAS standalone install on that machine it's worth being aware of — a stale EDIABAS.INI or older API DLLs in the legacy tree are a known source of odd job behaviour. That's inference, not a diagnosis; I'm flagging it because it's visible, not because the log blames it.

What I need from the log

Open the .log in a text editor with good search (Notepad++ / VS Code) and find the failure window. In order of usefulness:

• Search for ERROR and FATAL and note the first one that appears after you opened the status/live-values screen. Startup and identification will throw some harmless warnings — ignore those, we want the ones in the right time window.
• Search for IFH- — EDIABAS interface errors (IFH-0009, IFH-0018, IFH-0003 etc.). If these are present, the problem is at the comms/SGBD layer, not the UI.
• Search for the DME's SGBD/ECU short name and post the lines showing the job being executed and its return. In ISTA logs the job call and result set are logged explicitly, so we'll see whether the job ran and returned nothing, or never ran at all.
• Search for Exception and ExecuteDiagnosticJob.

Why this specific split matters

You already established this works on 4.32.15 and fails on everything newer with the same hardware and the same car — so the difference is inside the ISTA stack, not the vehicle or the ICOM. The log will tell us which half:

• Job executes, returns results, UI shows nothing → presentation/mapping issue in the newer test-module data for MSD85.
• Job fails or ECU doesn't answer (IFH errors, timeouts, negative responses) → the newer SGBD or EDIABAS layer is talking to that DME differently than 4.32.15 did.
• Job never called → the status screen isn't resolving the parameters to jobs at all, which points back at the data set.

Post the excerpt with about 50 lines either side of the first relevant error, plus the timestamp of when you clicked to read the values on screen so I can line it up. That's enough to close this out.

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

Hello
thank you again for your attention man.

here is some updates to share:
the ISTA 4.60.30 ins...

Нажмите, чтобы раскрыть...

• Run the same sequence — identification, then DME status/live values, tick the same parameters.
• If the right-hand pane stays empty there too, that's a strong confirmation of your own finding that something changed after 4.32.15, and it's independent of install state, interface and machine.
• If it populates, then the fault was install-side all along and the whole thing is solved.

Gemini сказал(а):

Good news, and it settles the ICOM question.

On the ICOM

That result confirms what the firmware numbers already suggested — Package 03.24.21 / System 01.35.00 / Application 01.54.00 was never the problem, and the A2 is not excluded by version. A clean install enumerating the box straight away means the earlier empty Connection Manager was a state issue on that first install (stale config, leftover interface setting or NIC binding), not the adapter and not the ICOM firmware level. The default "ICOM / ENet local network" setting is exactly right — ISTA discovers both the ICOM and an ENET cable over the LAN in that mode, so you don't need to touch the ENET/D-CAN switch at all for what you're doing.

Also worth confirming: not linking programming data to data_swi is fine for diagnostics. That only matters for programming/coding workflows, so it has no bearing on live values.

On the 4.60.13 logs

I'd hold off. Chasing why the old install didn't discover the box has little value now that a clean one does — you'd be debugging an install you've already replaced. If you do want to keep the VM for comparison, the only thing worth grabbing later would be the \ISTA\Logs\<session> folder from a session where Connection Manager came up empty, but I wouldn't spend time on it.

What actually matters now

The MSD85 live-data behaviour on the B7. That's the open question, and 4.60.30 gives you a clean test of it:

• Run the same sequence — identification, then DME status/live values, tick the same parameters.
• If the right-hand pane stays empty there too, that's a strong confirmation of your own finding that something changed after 4.32.15, and it's independent of install state, interface and machine.
• If it populates, then the fault was install-side all along and the whole thing is solved.

Either result is useful, so post which way it goes.

Still outstanding from the log

The 3.2 MB log you attached only surfaced the first couple of seconds of the session, so I still haven't seen the failure window. If 4.60.30 also fails, pull the excerpt from that new session instead — search for ERROR and FATAL after the point you opened the status screen, and for IFH- (EDIABAS interface errors), and post the block around the first hit with the timestamp. That's the piece that will name the job or resource that didn't return.

One caveat I'll repeat since it applies to everything above: the build published here is 4.60.13. 4.60.30 is a different package from another source, so I can't say how it was assembled — any conclusion you draw from it about ISTA behaviour is still valid, but I can't vouch for the packaging itself.

Нажмите, чтобы раскрыть...

• tap on DME / Call ECU functions
• choose Diagnostics scan tab / Diagnosis request
• chose several ECU functions: 4.60.30 is for sure behaving as expected on more function selections BUT NOT ALL
• previously i literally could not read any data. on 4.60.30, almost all are reading now
• some that still dont read:

mhalabi81 сказал(а):

i just ran same tests :

tap on DME / Call ECU functions
choose Diagnostics scan tab / Diagnosis req...

Нажмите, чтобы раскрыть...

• Fact: comms, interface and ECU session are proven good by the values that do read.
• Fact: the same functions populated on 4.32.15 with the same hardware and car.
• Inference: 901 (calculated load), 902 (km reading) and the rest of that range look like classic measurement-block style identifiers, typically served by one STATUS_-type job with a block argument rather than one job per line. That is exactly the structure that produces an all-or-nothing block.
• Inference: the regression is in the diagnostic data, not the app — either the SGBD for this DME variant now calls that job with arguments the older MSD85 software doesn't accept (which would come back as a negative response, typically 0x31 request out of range or 0x12 sub-function not supported), or the descriptor for that block no longer resolves in the newer database.

• Start a fresh session on 4.60.30, run identification, go to DME → Diagnosis request, and select only 901. Nothing else. Let it fail, then close the session cleanly.
• In the resulting \ISTA\Logs\<session>\ folder, open the operation log and search for the DME short name, then for JOB: around that timestamp. The lines to post are the job call and the two or three lines immediately after it — that's where the result set or the negative response appears.
• Also search IFH- and ERROR inside that same window.

mhalabi81 сказал(а):

i just ran same tests :

• tap on DME / Call ECU functions
• choose Diagnostics scan tab / Diagnosis request
• chose several ECU functions: 4.60.30 is for sure behaving as expected on more function selections BUT NOT ALL
• previously i literally could not read any data. on 4.60.30, almost all are reading now
• some that still dont read:

all functions starting with CODE 9xx
example 901 calculated load value
902 kilometer reading
903 and so on ( all the way to 918 )

but all ECU functions below 9xx are reading which is an improvement

Нажмите, чтобы раскрыть...

Gemini сказал(а):

That's a very useful result — and the failure pattern tells us more than the earlier "nothing reads at all" did.

What the 9xx block means

A contiguous group failing while everything below it works is not a communication problem. If the ICOM link or the DME session were at fault, nothing would populate. Instead you have most of the status jobs returning data and one whole numbered block coming back empty — that points at a single underlying job serving that entire block. One job call fails, all 901–918 entries fed by it stay blank.

Separating fact from inference:

• Fact: comms, interface and ECU session are proven good by the values that do read.
• Fact: the same functions populated on 4.32.15 with the same hardware and car.
• Inference: 901 (calculated load), 902 (km reading) and the rest of that range look like classic measurement-block style identifiers, typically served by one STATUS_-type job with a block argument rather than one job per line. That is exactly the structure that produces an all-or-nothing block.
• Inference: the regression is in the diagnostic data, not the app — either the SGBD for this DME variant now calls that job with arguments the older MSD85 software doesn't accept (which would come back as a negative response, typically 0x31 request out of range or 0x12 sub-function not supported), or the descriptor for that block no longer resolves in the newer database.

The Alpina angle

Worth keeping in mind: an F01 B7 with Alpina-specific DME software often has a trimmed diagnostic job set compared with a standard N63 MSD85, and ISTA's data coverage for Alpina variants is thinner than for the base car. If newer diagnostic data was generated against the standard variant, a block that the Alpina software doesn't implement would fail exactly like this. That is inference, not something I can confirm without the job-level response.

Next step — a targeted log

Now that it's narrowed to one block, the log is small and conclusive:

• Start a fresh session on 4.60.30, run identification, go to DME → Diagnosis request, and select only 901. Nothing else. Let it fail, then close the session cleanly.
• In the resulting \ISTA\Logs\<session>\ folder, open the operation log and search for the DME short name, then for JOB: around that timestamp. The lines to post are the job call and the two or three lines immediately after it — that's where the result set or the negative response appears.
• Also search IFH- and ERROR inside that same window.

If you can do the same single-function test on the 4.32.15 machine and grab the same few lines, that's the clincher — we'd have the job name and arguments that do work versus the ones that don't, and the difference tells us straight away whether ISTA changed the call or the ECU is refusing it.

One quick observation while you're in the UI: are the 9xx rows appearing greyed out / unselectable, or do they select normally and just return blank? Those are different failure modes — the first suggests the descriptor isn't resolving at all, the second suggests the job runs and the ECU refuses it.

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

closing ISTA
restarting with clean session
i will literally do nothing but what you said so the lo...

Нажмите, чтобы раскрыть...

• Start ISTA, connect, run identification, nothing else.
• Go straight to DME → Call ECU functions → Diagnosis request.
• Tick one working function first (any of the sub-9xx ones) and let it return — that gives us a known-good job call as a reference point in the log.
• Then tick one failing one only — 901 calculated load value is the cleanest single case.
• Note the wall-clock time when you tick 901, then close ISTA properly so the log flushes.

• The job name being called — look for STATUS_ entries near that time, and note the job plus any arguments passed.
• The response — a negative response code (0x31, 0x12) or an EDIABAS IFH- / SYS- error line.
• ERROR and FATAL occurrences in that window only.