NefMoto

I apologise for my first post being a question, but I don't (yet) have a lot to bring to the table!

After reading threads on here about how the 032RP is a pain to work with (from 05 Seat Ibiza Cupra 1.8t 180hp) and being fairly new to this, I bought myself a similar ECU to cross flash and use as a test bed, from a Ibiza FR 1.8T 150hp. I have read that a user (nottingham?) on here has had success cross flashing this config

I am bench flashing with a lab supply at 14.00V.
I have both cheap ebay MPPS and cheap ebay Blue VCDS interfaces.
Initially I had to do Immo_off to get anywhere, which I seem to have successfully done using the helpful info on here and writing via the K line in boot mode.
With the Immo off, I still can't read or write any file to the ECU with Nefmoto, but it will connect in normal mode then give "security access not granted" when I attempt to read.  I cannot connect in boot mode.

With MPPS I have successfully downloaded the original QN Flash, then uploaded an 032RP original map I downloaded from here. Initially it got stuck in a bit of a loop waking the ECU up etc, so I powered off and tried again. I used the MPPS checksum option to make the RP map match the QN source (I guess I shouldn't have done this?)

Everything connects OK after flashing and the ECU now reports that it is 032RP in MPPS, Nefmoto and VCDS, and lists a few fault codes related to not being plugged in to anything I presume. I cleared these, powered off the ECU and fitted it to the car.

The car will not start at all, and a brief check showed no fault codes?

Do I need to modify the EEPROM to match the new cross flashed map or have I missed something obvious?

I forgot to add, the results of ME7Check seem to show that they are compatible:

-> Bootrom Version = 05.12
-> EPK = 41/1/ME7.5/51/4518.07//24C/Dst01o/120903//
-> Contents of ECUID data table:
   - '0261208370'         (SSECUHN)
   - '1037369321'         (SSECUSN)
   - '06A906032QN '       (VAG part number)
   - '0010'               (VAG sw number)
   - '1.8I R4/5VT     '   (engine id)
-> Contents of ECUID data table:
   - 'HW_MAN004'

VS

Reading Version Strings...
-> Bootrom Version = 05.12
-> EPK = 39/1/ME7.5/51/X505R//24C/Dst03o/190504/
-> Contents of ECUID data table:
   - '0261208521'         (SSECUHN)
   - '1037371739'         (SSECUSN)
   - '06A906032RP '       (VAG part number)
   - '0010'               (VAG sw number)
   - '1.8I R4/5VT     '   (engine id)
-> Contents of ECUID data table:
   - 'HW_MAN004'

I just hooked the ECU up on the bench and ran VCDS, and have found it's storing a
"18017/P1609/005641 - Crash Shut-Down Activated" fault code,
It seems I've answered my own question!

Did you solve the problem?

Nope, the code won't clear using VCDS (Well, it and the other 8 codes come back after a power cycle)
AFAIK it should clear itself when the ignition is cycled anyway, so there's definitely something amiss.
I'm suspecting this is actually a problem with the ECU I bought (from a scrapyard so I presume crashed vehicle) rather than anything I've done wrong.

That said I have also seen this code attributed to the immobiliser, so perhaps my Immo_off eeprom is incorrect. I would expect it to start then immediately cut out if it was an immo fault though.

Connect to engine, adaptations, channel 91. What is displayed?

Thanks ddilinger,
I only have VCDS-Lite on the workshop PC which won't let me read channel 91, I have lent out my licenced tablet. Great timing eh? I'll hook it up Monday and see what it shows. What should I be expecting?

Righto.
Channel 91 stored value is 1.

1 = immo off
4 = immo active

Thanks, that does confirm that my problem must lie with this crash sensor fault.

I presume that it automatically resets when the ECU is power cycled on a vehicle, with an airbag controller etc to talk to to confirm that it isn't still being crashed.
Obviously it must have been removed from a crashed car, and immediately on receiving it I opened it up and turned the immo off before writing the new map, this process has allowed something to fall out of sync.

I might try rewriting stock EEPROM/flash, putting it on the car and attempt to start it in the hope that it will allow it complete whatever cycle it needed to do to clear the p1609.

Did you not clone your EEPROM to the new ECU?

If not the QN ECU probably comes from a crashed vehicle with the crash code stored to the E2P.

Yeah, that's what I presume.

I'm wary about doing anything with my ECU if I can avoid it, It has a suspected Revo tune so I'm expecting problems if I do try an connect to it.
That said, a boot mode read of the EEprom shouldn't trip any copy protection crippling stuff.

I've spent some more time on this tonight. The fault code is still persistent, even with a completely different ME7.5 EEPROM file loaded from another, uncrashed ECU. I confirmed the EEPROM had uploaded successfully by checking for immo_off as above (the test file I used has it still enabled) and also by reading it back off the ECU.

I've traced the "crash signal" input from pin 67 on the ecu, via a 2k2 pull down resistor and a 33k buffer resistor network into pin 19 of the 30380. Everything seems good, it's pulled down OK and the input to the IC seems OK too (it gives an identical "diode test to ground" voltage as other, known working inputs so it is unlikely to have suffered any external damage from a voltage spike in the crash etc etc)

I was under the impression that the adaptations and fault codes were stored in the 95040 EEPROM? obviously I've either got something wrong there or there is some hard fault on the ECU causing this code.

I've come to a bit of a dead end really. I'm really tempted to just do an EEPROM read from my working ECU, but it's likely got a Revo map on there.
Will reading the EEPROM off it via bootmode leave any trace (like when Nefmoto does a read and leaves a signature in the EEPROM)

Right! Success!

Using a stock RP Map downloaded off here, and the EEPROM read from my original ECU it starts and runs.

I'm currently reading the supposed Revo tune off my original ECU, safe in the knowledge I have an original EEPROM file to re-upload if it trips something out.

Thanks for the help both in this thread and for the info generally all over the forum. Once I've got a bit further and have a decent XDF made that I can verify actually works in practice I will share it on here and try to give something back.