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

Gemini сказал(а):

Perfect — that's exactly the right approach, a minimal session makes the log far easier to read.

Sequence to run

• 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.

Two reads in one session and nothing else means the failure window will be a small, obvious block instead of something buried in a few hundred thousand lines.

What to pull out afterwards

Open the new IstaOperation.log and search around the timestamp of the 901 request for:

• 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.

If the block is compact, paste it inline with ~50 lines either side. If it's large, zip and attach. Either way, tell me which function you ticked first and which failed, so I can line the two job calls up against each other.

On the packaging point from your last post — correct, 4.60.30 isn't the build published here, so I can't speak to how it was assembled. But that doesn't affect this analysis: what we're chasing is a job/SGBD behaviour against the DME, and the log will show that regardless of who put the package together.

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

mhalabi81 сказал(а):

strange thing: this version does not keep or write any logs in the \BMW\ISPI\TRIC\ISTA\Logs folder
i...

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

• Open the config: <install root>\TesterGUI\bin\Release\ISTAGUI.exe.config and look for these keys:

<add key="BMW.Rheingold.Logging.Directory" value="..\..\..\Logs" />
<add key="BMW.Rheingold.CoreFramework.DebugLevel" value="9" />
<add key="BMW.Rheingold.Logging.AutoFlush" value="True" />
<add key="BMW.Rheingold.Temp" value="C:\Temp" />

• Whatever Logging.Directory says is where the session folders go. If DebugLevel is 0 or missing, set it to 9, set AutoFlush to True, save, and restart ISTA.
• If you'd rather not guess, just search the whole drive for IstaOperation.log sorted by date modified — the newest hit is your session folder. From an admin prompt:

dir C:\IstaOperation.log /s /b /o-d

• Also check C:\Temp and %LOCALAPPDATA%\Temp\<timestamp>_<guid>\ — the process creates a temp folder per session with the same GUID as the log folder, so if the temp one exists you can match the GUID.

Gemini сказал(а):

Not strange, actually — that's the most likely explanation given what we already saw.

Why

In the log you posted from the other machine, ISTA was installed at C:\EC-APPS\ISTA\ and it wrote to C:\EC-APPS\ISTA\Logs\20260907_091812_<guid>\. That path came from BMW.Rheingold.Logging.Directory = ..\..\..\Logs, i.e. relative to TesterGUI\bin\Release. So the log folder follows the install root, not the standard \BMW\ISPI\TRIC\ISTA\ location. If 4.60.30 is installed somewhere else, its Logs folder is under that root — nothing has been redirected maliciously, it's just relative.

The second possibility is that DebugLevel is 0 in this package. At 0 you get little or nothing written. Your earlier install had it at 9, which is why that file was 3.2 MB.

How to find it in two minutes

• Open the config: <install root>\TesterGUI\bin\Release\ISTAGUI.exe.config and look for these keys:

XML:

<add key="BMW.Rheingold.Logging.Directory" value="..\..\..\Logs" />
<add key="BMW.Rheingold.CoreFramework.DebugLevel" value="9" />
<add key="BMW.Rheingold.Logging.AutoFlush" value="True" />
<add key="BMW.Rheingold.Temp" value="C:\Temp" />

• Whatever Logging.Directory says is where the session folders go. If DebugLevel is 0 or missing, set it to 9, set AutoFlush to True, save, and restart ISTA.
• If you'd rather not guess, just search the whole drive for IstaOperation.log sorted by date modified — the newest hit is your session folder. From an admin prompt:

Код:

dir C:\IstaOperation.log /s /b /o-d

• Also check C:\Temp and %LOCALAPPDATA%\Temp\<timestamp>_<guid>\ — the process creates a temp folder per session with the same GUID as the log folder, so if the temp one exists you can match the GUID.

One caution

Edit the config with ISTA closed, and keep a copy of the original before changing anything. Also note the log folder is created at process start, so a session you already ran with logging off can't be recovered — you'll need to re-run the 901 test after enabling it.

Post the install root path for 4.60.30 and what Logging.Directory and DebugLevel are set to, and I'll tell you exactly where to look.

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

mhalabi81 сказал(а):

i was doing exactly what you mentioned .. funny you beat me to it
<appSettings>
<add key="BMW.Rh...

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

echo %ISPIDATA%

<add key="BMW.Rheingold.Logging.AutoFlush" value="True"/>

• Below roughly 12.5 V resting, ISTA starts refusing or aborting jobs and you get blank fields that look exactly like the fault we're chasing. If you log a session on a weak battery you'll be reading noise.
• A standard trickle charger often can't keep up with a woken-up F01 running a full diagnostic session — the bus alone pulls a fair amount. A proper 70 A+ workshop supply is what these need. If you don't have one, a drive followed by a short session on a rested battery is the practical substitute.