# F01 RSE Flash Fail



## stuartjohn24 (Jun 1, 2011)

Hello all,

I hope some of you can help me! I am retrofitting RSE into my 2008 F01, pretty much everything has been going to plan until I received the RSE module from a dishonest eBay seller this week! 

The unit was sold to me as working but upon fitting the module to my F01 it did not power up and display anything on the monitors, Rheingold showed the module in RED and was unable to communicate with it.

I tried E-SYS and the module showed up in the SVT tree but with an exclamation mark on its folder icon, the error message when hovering the cursor on the icon read:



> SVK invalid: programming dependencies check failed (02). [C242]


Not looking good, the module tree broke down to the following:



> BTLD_000005D2_002_015_001
> HWEL_0000061E_001_007_003
> SWFL_00000434_002_017_001
> SWFL_00000435_002_013_002
> ...


My F01 was recently updated to I-Step F001-15-03-503 by a BMW dealer shortly before I purchased the car in May. I have F001-15-03-503 psdzdata loaded into E-SYS and would like to update the RSE to this level whilst I have the opportunity.

I ran an SVT target calculation based on my original I-Step being F001-08-09-521 and the target being F001-15-03-503. The result was as follows:



> BTLD_000005D2_002_015_001
> CAFD_00000168_002_005_010
> HWEL_0000061E_001_007_003
> SWFL_00000432_002_015_001
> ...


From this I have gathered that the RSE module with part number 65 12 9245460 manufactured between Sept 10 to Mar 11 has a compatible HWEL, someone has already attempted to flash the RSE recently as the BTLD and some of the SWFL files are in black, although I don't know under what I-Step the software was released.

E-SYS has identified the correct SWFL files that are showing up as 'UNKN' and made them the target.

I went ahead and generated the TAL, processed only the RSE and started the flash. The bootloader file went in and installed no problem, so did the first three SWFL files and then it hung finalising the fourth, I have posted the error log below, please note I tired this 4 times in total, the first with the bootloader (although it was updated anyway) and three times with just the SWFL files i.e. swDeploy checked. The log refers to one of these attempts, all four attempts fail at exactly the same point with the same error:



> TAL execution started.
> VCM Update: VCM-Update is deactivated. VCM will not be updated. (C197)
> ExecutionID=2015/07/16-19:52:29.053
> () prepareTALExecution started
> ...


If anyone can help or has any suggestions they will be greatly received!

Many thanks in advance

Regards

Stuart


----------



## milkyway (Jan 28, 2013)

Hello!

To be clear. You modified the VO and added the SA for the RSE? You didn't tried to inject a CAFD into the RSE ECU before you tried to flash it?

CU Oliver


----------



## stuartjohn24 (Jun 1, 2011)

Hello,

Thanks for the quick reply Milkyway!

Yes thats correct, I have added 6FG to VO/FA. I tried to inject a CAFD file (CAFD_00000168_002_005_010) but this was unsucessful, coding resulted in error code [433] negative response conditions not correct. I then initially tried to flash it with that CAFD file.

Stuart


----------



## milkyway (Jan 28, 2013)

Hello!

Are you sure the RSE ECU comes from a F01?

CU Oliver


----------



## stuartjohn24 (Jun 1, 2011)

I am not 100%, it may have originally been fitted to an F10, however the part number cross references to the 5 and 7 series, I didnt think this would be an issue.

I have a suspicion that the 'Code Default Values' button may have been pressed by the previous owner.

Regards

Stuart


----------



## ap90500 (Oct 23, 2013)

I don't think that the problem is in "code default values" as it should only corrupt CAFD (and maybe BTLD). My bets are on faulty device, obviously it was broken in the beginning if the SWFL files were corrupted. According to my knowledge, if HWEL matches, then all calculated files are ok. All control units with the same exact HWEL should be identical.


----------



## stuartjohn24 (Jun 1, 2011)

Hello ap90500,

I think you are right, I have seen posts where some of the SWFL files are corrupted / UNKN but the cause of those were failed flashes because the HWEL numbers were incorrect during SVT/TAL calculation, I'm 100% sure what I'm doing is correct. 

I have sourced another RSE module so hopefully that will work better than this one! I can see at least one flash memory device on the main board, it's got the red lacquer over the IC's so can't read the part numbers off until I take it into work.

I might have a play around with it, hopefully the boot loader is stored in the main control processor internal memory so replacing the external program flash memory may be viable. 

I will report back if I make any progress.

Stuart


----------



## ap90500 (Oct 23, 2013)

At least on some f-series modules bootloader update goes like this: First new btld is written over some SWFL('s). Then inside control unit, data is transfered to actual memory space of the bootloader. This leads to situation that the bootloader is ok, but some swfl's are not. If update gets cancelled at this point, result is BTLD ok and SWFL not ok.

I am not sure if this is the situation here. You can try with just updating bootloader and then check if there are some extra FFFFFF SWFL files. Still I think that selected files are correct, and I am 99% sure that you did everything correctly.

Have you BTW connected all required cables to your RSE? I have never done this but I think that MOST, ethernet and maybe K-CAN is required.


----------



## stuartjohn24 (Jun 1, 2011)

I understand, in my day job we design the system such that a unit can never be in-recoverable. For example an external flash memory is used as a backup, when a software update is initiated the entire boot loader and application code is written to an external flash memory by the current operating software, once complete the data is checked to ensure it copied ok and the checksums check out then it copies the new software over to it internal memory. At every power up the software is checked internally and externally, if there is an issue with either then they overwrite. This is a system with a high safety integration level I assume it's not cost effective to this in the automotive industry!

But I agree, so long as the boot loader is ok then it should be able to sort itself out and allow you to program new application code.

It takes the boot loader ok and there are no extra SWFL files than those listed above, the MOST works fine with the unit fitted, so there is some dumb functionality there as it's able to log itself into the network with the correct address as rheingold can see it. The Oasis NIC is not just in pass-through mode.

I can also initiate a software flash and download the boot loader and then the SWFL files, to me it looks as though it downloads one of the SWFL but is unable to write it to the memory, the error refers to erasing some part of the flash which is where it hangs.

Yes, everything is connected, it's simply power, MOST, LVDS to monitors and the optical headset interface, terminal 58G for illumination and CVBS from digital TV module. I have the basic RSE so no Ethernet link to CIC.


----------



## ap90500 (Oct 23, 2013)

Actually there was one case a few months ago. A guy tried to flash ZGW of his car. Bl-upload and install went fine. After this, SWFL upload failed. He tried with ICOM and ENET, with same result. He bought used ZGW and had the same result. In the end he sent one of these two modules to me and I flashed it on desk without problems. The other module was recovered by his friend, without problems.

Which interface are you using? I have had problems with ten meters long ENET cable, it is possible that BMW zgw ethernet connection does not fulfill ethernet standard.


----------



## stuartjohn24 (Jun 1, 2011)

Interesting, I am using ENET, I made the lead myself, it's only about 3M long at most and it's made using screened industrial Ethernet cable. So just the 4 cores and an IDC type screened RJ45. Here is a picture:



Stuart


----------



## stuartjohn24 (Jun 1, 2011)

Here is the screen shot after SVT has been calculated, I used my I-Step and the target I-Step that my F01 has already been updated to.



Stuart


----------



## stuartjohn24 (Jun 1, 2011)

I have been examining the PCB of the RSE unit this afternoon, noticed there is a Maxim RS232 transceiver on the bottom of the board, which I thought was strange. Anyway dug around in the psdzdaten folder and pulled out the SWFL and BTLD files. This is where things got interesting in a geeky kind of way!!

I opened up the boot loader file, and the build date was Feb 16 2011, so not many updates for a while!

What I found interesting is within the pages of machine code is what looks like an extensive diagnostic menu!
Menu name: PL6 RSE Starter
Options like, ECU reset, go to application, application info, go to download, SRAM test etc...

Then a menus showing MOST info, edit serial number, edit programming date, erase SWE, test startup for re flash etc...

Something tells me having a look at this may be worth a shot! It may give me a much lower level diagnostic interface than E-SYS and Rheingold can. 

I will get the thing powered up and connected to an RS232 adapter on Monday, I bet the interface is wired out to unused pins on the connector! 

I will report back any findings!

Stuart


----------



## stuartjohn24 (Jun 1, 2011)

Well, the last day or so has been interesting, I have figured out what part of the flash is failing.

The SWFL files break down to the following:



> SWFL_00000432_002_015_001 - Media player config
> SWFL_00000433_002_015_001 - MHI user interface
> SWFL_00000434_002_017_001 - uicapp
> SWFL_00000435_002_013_002 - aspapp
> ...


The flash process successfully completes the 'uicapp' which seems to be similar to the actual boot loader, the 'aspapp' which appears to be for the DSP and finally the FPGA firmware.

The process hangs when it gets to writing the VGC Bootloader. It seems to download the 512Kb file to RAM and then times out when trying to actually transfer it to the FLASH memory.

I modified the xml file for the VGC boot loader such that it instructed e-sys to flash the 'aspapp' file again thinking it was completing VGC boot loader, this completed successfully as expected essentially skipping the VGC boot loader section.

The flash continued with writing the 27MB VCG application software. Basically there is a video decoder processor that decodes the DVD and video sources and generates the actual video data, its an NXP PNX9520. It has an external flash memory 64MB is size that holds the VGC Bootloader, VGC Application Software and the HMI user interface files.

The flash continued to 43% then crashed, with a general flash fault, I tried again but it failed again at 21% with the same error, e-sys retries automatically a second time but each time I get the same error as before, error erasing flash memory.

The PNX9520 cannot flash its external memory itself, the flash memory sits on a bus and in-between the flash and the PNX9520 are two tri-state buffers, when the flash memory is to be updated the flash memory is disconnected from the PNX9520 and connected to the main processor, the main processor then flashes the memory with the software downloaded over the MOST interface.

The boot loader fails every time, but the VGC application does begin to flash OK, this would suggest the addressing and switching of the memory to the processor is working but the flash memory could be faulty.

I haven't really got anything to lose now, I have removed the flash memory and ordered a replacement, its a Micron JS28F512P33BFD.

Hopefully this will fix it!

Anyway, as I suspected the RS232 is wired to two unused pins on the main connector, you can connect this up to a terminal program and see whats going on! The main processor looks healthy and any button presses are reported in the terminal and all of the reset and wake information is listed along with the processor boot sequence. there is a menu table but I have been unsuccessful in getting into any of the options as of yet. Will see if a blank flash memory and another go on e-sys will yield any results!

Stuart


----------



## clocKwize (Mar 15, 2016)

Any luck with this? I'm experiencing exactly the same issues, except mine is factory fitted and I just did a I-step upgrade to the whole car.. Not sure what to do now :|


----------



## 7nachik7 (May 12, 2013)

When flash fail, you have to udate the corrupted btl or swfl (UNKN_FFFFFF) one by one and not all together. After last corrupted file updated you can then insert cafd and your rse will work. I will write to you the procedure when i will back home.


----------



## clocKwize (Mar 15, 2016)

That would be great. I didn't know it was possible to update them one by one. Its only SWFL that are UNKN. so I guess its not too broken to fix as the bootloader is ok  Thank you


----------



## clocKwize (Mar 15, 2016)

I have fixed this now. I used a new version of ISTA/P. 

I noticed in the release notes of a slightly older version it said there was a bug flashing some ethernet stuff (RSE included).

I thought that maybe E-Sys had the same issue, so I went and found the latest version of ISTA/P that didn't include this bug in the release notes, took far longer than E-Sys but worked fine.

Running ISTA/P 3.58.2.001 (which as far as I can find online, is the latest).


----------

