[____ANGEL___]

Problem solved, not wiring problems, just choose correct option before flash

---

99.99% there are problem on your bench wiring, it should show "performEcuFlash started with protocol HTTP" on swfl/iba flashing, and not UDS.

update NBT with UDS will spend a week 

Youre wrong 

Because every one of you playing around the rumor that deactivate http transmission and deactivate parallel programming resolve all issues, you are wrong first, that 2 options are useless. Try to understand what is described in tal and you never have issues.... Prerequisites.... Protocols......

(Ps. ista uses parallel programming and http transmission every day at every world dealer)

Cheers....

---

Due suddenly stop while flashing in CAN mode before, after finished in ENET mode flashing i got these errors, how to fix ?
Updated: I tried to edit UNKN_FFFFFFFF_255_255_255 to IBAD_00000000_000_000_000 in SVT_IST and reflashed but still got same errors.

[HU_NBT - 63 - ibad_00001277-003_013_001] Transaction type: ibaDeploy;  Message: 86% progress on ECUId:HU_NBT_0x63 [99% of ibad_00001277-003_013_001] [TRANSACTION]
MCDDiagService<id=333200, job=com.bmw.psdz.jobs.http.MCD3_PerformECUFlash_Http, service=RC_CHECK_MEMORY_HTTP - RoutineControl CheckMemoryHttp, description=error: positive response with negative content, link=HU_NBT_63_ETHERNET_63> [DIAGSERVICE]
[HU_NBT - 63 - ibad_00001277-003_013_001] Transaction type: ibaDeploy;  Message: 86% progress on ECUId:HU_NBT_0x63 [100% of ibad_00001277-003_013_001] [TRANSACTION]
[] job failed with negative response error: 
 code: result of the routine control service is not correct
 description: service RoutineControl CheckMemoryHttp returned unexpected result: debugInformation_02_FF; LinkName: HU_NBT_63_ETHERNET_63
 severity: FATAL ERROR
 [THROWABLE]
[HU_NBT - 63 - ibad_00001277-003_013_001] Transaction type: ibaDeploy;  Message: TA finished [TRANSACTION]
[HU_NBT - 63] There was an error during TAL execution, please check the log files. [WARN]
[HU_NBT - 63] - [Exception - HU_NBT - 63] job failed with negative response error: 
 code: result of the routine control service is not correct
 description: service RoutineControl CheckMemoryHttp returned unexpected result: debugInformation_02_FF; LinkName: HU_NBT_63_ETHERNET_63
 severity: FATAL ERROR

[HU_NBT - 63] finalizeECUFlash started [PROGRESS]
[HU_NBT - 63] finalizeECUFlash finished [PROGRESS]
[] There was an error, please check the log files. [WARN]
[] - [Exception - HU_NBT - 63] job failed with negative response error: 
 code: result of the routine control service is not correct
 description: service RoutineControl CheckMemoryHttp returned unexpected result: debugInformation_02_FF; LinkName: HU_NBT_63_ETHERNET_63
 severity: FATAL ERROR

[] finalizeVehicleFlash started [PROGRESS]
[] finalizeVehicleFlash finished [PROGRESS]
[] prepareVehicleForCoding started [PROGRESS]
[] prepareVehicleForCoding finished [PROGRESS]
[] finalizeVehicleCoding started [PROGRESS]
[] finalizeVehicleCoding finished [PROGRESS]
[] finalizeTALExecution started [PROGRESS]
[] finalizeTALExecution finished [PROGRESS]
TAL execution finished [TAL_EXECUTION_FINISHED]
TAL-Execution finished with status: "FinishedWithError". [C207]
TAL execution finished. Duration: "21min 52s". [C206]

edit svt ecu is useless.... since tal is created from delta svt ecu and svt calculate, everything that don't match with svt calculate will be overwritten. Make sure that: Car is in original state, FA is in original state, i-step shipment is in original state. Calculate a new tal without editing nothing and post here. Don't press hwids from actual, other rumor.... All of these particular things like hwids etc are for cases with hardware parts not allowed on the car, or other particularity.

[BlueMeetsWhite]

Had the same issue this week replacing the hard drive in an NBT, and have been vexed by this issue for a year or so.

I tried 2 hardware DHCP servers (different brands) with no luck.  I tried software DHCP with the same result.

I ended up flashing the NBT over UDS (5.5-6 hours).

When I finished, a colleague mentioned that he'd had the same issue and had to use an older version of eSys to flash over HTTP.

He used 3.31 and I found a guy on another forum who said 3.28 worked for him.  In fact, he went on to say he used the same tal, svt and fa calculations in both 3.28 and 3.34.  3.28 worked perfectly over HTTP and 3.34 reverted to UDS.

Unfortunately this NBT was for a customer - and I didn't have time to reflash it with an older version.  I will try it next time, but if you give it a go ... PLEASE PLEASE PLEASE, report back and let us all know if it worked!

I flash with ISTA and this process takes so long, but i don’t know with the settings.

Yes I agree.  I've had this a few times now - I've always used hardware DHCP (tried two different routers) but ISTA reverts to UDS (slow connection).  Only thing I haven't tried is a software DHCP server.

[DieStream]

Had the same issue this week replacing the hard drive in an NBT, and have been vexed by this issue for a year or so.

I tried 2 hardware DHCP servers (different brands) with no luck.  I tried software DHCP with the same result.

I ended up flashing the NBT over UDS (5.5-6 hours).

When I finished, a colleague mentioned that he'd had the same issue and had to use an older version of eSys to flash over HTTP.

He used 3.31 and I found a guy on another forum who said 3.28 worked for him.  In fact, he went on to say he used the same tal, svt and fa calculations in both 3.28 and 3.34.  3.28 worked perfectly over HTTP and 3.34 reverted to UDS.

Unfortunately this NBT was for a customer - and I didn't have time to reflash it with an older version.  I will try it next time, but if you give it a go ... PLEASE PLEASE PLEASE, report back and let us all know if it worked!

I flash with ISTA and this process takes so long, but i don’t know with the settings.

Yes I agree.  I've had this a few times now - I've always used hardware DHCP (tried two different routers) but ISTA reverts to UDS (slow connection).  Only thing I haven't tried is a software DHCP server.

I use a software DHCP Server, but yesterday i need 9 Hours to flash NBT, 6WB and HuD.

[BlueMeetsWhite]

Don't see how wrong interface setting could impact that.

Most probably it went using UDS protocol instead of HTTP which is much quicker. The main question then is: Is firewall configured properly (it is mandatory for http protocol)? How did you install your ISTA?

However flashing code verifies stability of http connection and if packet loss is too high, goes to UDS automatically. It happens from time to time and there is little you can do except ensure your computer is properly configured, you use good quality HW, cables, etc.

Just a working hypothesis at the moment, with more work required to prove it but it may give somebody, somewhere an idea to solving this frustrating annoyance!

It is reported if you use eSys 3.31 or lower happily flashed NBT over HTTP.  A colleague confirms this - on the bench he uses 3.28 and believes he may have used 3.31 (hopefully we'll reproduce this in time)

So what changed at 3.32 onwards?  A lot probably, but noticeably in the release notes 3.32 is verified with Java 1.8 ... so did something in one of the java classes, or even the third party java classes change?  Again, conjecture at the moment.

eSys 3.31 .... Java-Version (verified with): 1.6.0_27 & 1.7.0.51 32 Bit & 1.8.0.66 32 Bit
eSys 3.32 - Java-Version (verified with): 1.8.0.92 32 Bit

At 3.33.4 the following know issues appears in the release notes ....

15771 - Data Tranfer Speed
15770 - No Parallel Flash mit URL Connection

So eSys and ISTA are both Java applications.  They undoubtedly use shared classes....

Been sitting here all evening decompiling Java classes.  Nothing yet, but I'm no Java pro

Anyone know anyone on the inside who could look up those two known issues?

Is eSys open source?  I know some of the components it uses are.

[ir655]

Flashed NBT HU with 4.36.40 data for my F11 using e-sys 3.30.1. It took maybe 30min-45minutes.

Recieved http error trying to flash using e-sys 3.36.x.

[Node]

So eSys and ISTA are both Java applications.  They undoubtedly use shared classes....

Is eSys open source?  I know some of the components it uses are.

ISTA is NOT Java application in itself. It's a .NET application. For flashing however, it starts psdzdatahost application which IS java.

Of course not.

[Matthew53]

I'll describe my situation.

Yesterday I successfully flashed NBT via HTTP using ENET with esys version 3.30. Today I wanted to flash the same unit with the same files, the same PC, the same ENET cable and the same bench setup and it throws an error:

"[] Activate programming mode was not successful for: ECUId:HU_NBT_0x63 [WARN]
[] ECUId:HU_NBT_0x63 not accessible cause could not be switched to parallel programming mode [WARN]"

Of course I can't deactivate programming mode for switchable ECUs, because it automatically switch to UDS and it take 1% every 10minutes for only one SWFL (read - forever).

The same fault on 3.27 version and when using ICOM with DHCP-server.

So it looks a little like esys can throw a fault randomly, but it sound crazy I know. However I can't find other explanation for now.

If anyone has a clue about the fault I get, I would be grateful.

[ir655]

I'll describe my situation.

Yesterday I successfully flashed NBT via HTTP using ENET with esys version 3.30. Today I wanted to flash the same unit with the same files, the same PC, the same ENET cable and the same bench setup and it throws an error:

"[] Activate programming mode was not successful for: ECUId:HU_NBT_0x63 [WARN]
[] ECUId:HU_NBT_0x63 not accessible cause could not be switched to parallel programming mode [WARN]"

Of course I can't deactivate programming mode for switchable ECUs, because it automatically switch to UDS and it take 1% every 10minutes for only one SWFL (read - forever).

The same fault on 3.27 version and when using ICOM with DHCP-server.

So it looks a little like esys can throw a fault randomly, but it sound crazy I know. However I can't find other explanation for now.

If anyone has a clue about the fault I get, I would be grateful.

Post screenshots of your settings in ESYS options>settings>connections and also under TAL processing>parameters tab.

[Matthew53]

I'll describe my situation.

Yesterday I successfully flashed NBT via HTTP using ENET with esys version 3.30. Today I wanted to flash the same unit with the same files, the same PC, the same ENET cable and the same bench setup and it throws an error:

"[] Activate programming mode was not successful for: ECUId:HU_NBT_0x63 [WARN]
[] ECUId:HU_NBT_0x63 not accessible cause could not be switched to parallel programming mode [WARN]"

Of course I can't deactivate programming mode for switchable ECUs, because it automatically switch to UDS and it take 1% every 10minutes for only one SWFL (read - forever).

The same fault on 3.27 version and when using ICOM with DHCP-server.

So it looks a little like esys can throw a fault randomly, but it sound crazy I know. However I can't find other explanation for now.

If anyone has a clue about the fault I get, I would be grateful.

Post screenshots of your settings in ESYS options>settings>connections and also under TAL processing>parameters tab.

Here it is
       

EDIT: ok this is apparently NBT fault. I took another NBT and flash goes via HTTP with same settings with esys 3.30. But how is that possible that NBT could be flashed yesterday without any problems and today it throws a fault about activating programming mode.

[ir655]

I'll describe my situation.

Yesterday I successfully flashed NBT via HTTP using ENET with esys version 3.30. Today I wanted to flash the same unit with the same files, the same PC, the same ENET cable and the same bench setup and it throws an error:

"[] Activate programming mode was not successful for: ECUId:HU_NBT_0x63 [WARN]
[] ECUId:HU_NBT_0x63 not accessible cause could not be switched to parallel programming mode [WARN]"

Of course I can't deactivate programming mode for switchable ECUs, because it automatically switch to UDS and it take 1% every 10minutes for only one SWFL (read - forever).

The same fault on 3.27 version and when using ICOM with DHCP-server.

So it looks a little like esys can throw a fault randomly, but it sound crazy I know. However I can't find other explanation for now.

If anyone has a clue about the fault I get, I would be grateful.

Post screenshots of your settings in ESYS options>settings>connections and also under TAL processing>parameters tab.

Here it is


EDIT: ok this is apparently NBT fault. I took another NBT and flash goes via HTTP with same settings with esys 3.30. But how is that possible that NBT could be flashed yesterday without any problems and today it throws a fault about activating programming mode.

Thats what my settings look like. ALL other mudules flashed over UDS even with my settings being like yours except NBT for some reason went through HTTP.

Could be bug in esys or faulty NBT as you say I dont know. Have you tried flashing with newer version of esys? Also I made sure AV was off and all firewalls off.