Rlink2 HW 1.1 config file after update v2.3 to v7

[crs-ica]

Hello all,
I had my unit HW 1.1 updated from v2.3 to v7.
The steps were:

1. MICOM update from 4992 to 5615
2. Main app update directly from v2.3 to v8 (the one who helped me didn't had v7)
   After this, the unit is laggy (sometimes unusable) and the connection with the NXP dsp chip seems at least incomplete (no ESE).
   As I am an engineer I got to the research part and understood that I have to go to v7 (MICOM, CAN communication reason) and try to do a unit reconfiguration.
3. I did a downgrade to v7. Everything is the same.
4. I installed Pyren and generated a configuration file for my car with the bot. I saw in the results that the configuration file seems to be generated for my initial Rlink configuration file reference ID from v2.3 (281159453R) and not for the current one from v7 (281150445R). I tried to generate a config file with the new reference ID but the result is the same.

Can you please help me with this issue?
I am ready to learn how to generate the updated configuration file or give the necessary details to have it generated.

I owe an wireless ELM that seems ok till now even though I know is not the best option. At need I can buy another (wired) one.

Thank you very much for you time and help!

[matzel82]

Why do you this ?? It's really logical that's is happening like this... there are engineers who make radios... don't touch a running system

[shrlnm]

@crs-ica try with 281152288R

[crs-ica]

@matzel82 definitely not trying to make a debate here but these are my reasons:

1. I like my car. I really do and intend to keep it for at least the same period of time as of the one passed from purchasing.
2. I somehow missed the official under warranty update from v2 to v7.
3. During the last year I found myself wanting AA (long roads, way more safe usage of the phone -maps while driving)
4. I am a hardware developer of embedded electronics - I love to get messy from time to time with other devices. I learn new technologies, processes, systems, etc and it gives me a good mood, knowing that I am taking it from scratch and discovering the "wheel".
5. I am willing to pay the price of my curiosity - If I brick the unit, I will buy another one and this is it. If not i will be happy from multiple perspectives.
6. Hope I didn't offend anybody.

@shrlnm thank you for the suggestion. I see that your code is from a factory v3 unit (LANR16). The generated commands are slightly different at few addresses. I will compare those with the commands generated in the first place and with the documentation to understand those differences.
Do you have any idea why the bot cannot generate specific commands for my v7 code (281150445R)? It may be related to the fact that I haven't changed the unit (LANR14) per se and the code is a "virtual" one, not connected to an official unit that left the factory in that state?
Also, do you have a recommendation of what to change into the script when using a WiFi ELM to optimize the writing process?

[shrlnm]

@crs-ica the code (281150445R) is absent in the latest bvmextraction . You may check it yourself
Make all_vin file by the command
doc_maker.py --allvin XFD
The file will be created in bvmextraction/xfd
There you may find all combinations such as 76:281152518R 283C25611R which are related to XFD
The left number is "ID028 CONFIGURATION FILE REFERENCE LINK F188"
The right number is a configuration file name
Below is a list of all configuration files related to XFD

283C22233RF RadNav_v1.4_ALL.xml
283C20871RF RadNav_v1.4_XFD.xml
283C27106RF RadNav_v1.4_XFD.xml
283C23431RF RadNav_v1.5_20150831T113529.xml
283C24340RF RadNav_v1.9_20160513T120611.xml
283C25058RF RadNav_v1.9_20160513T120611.xml
283C28177RF RadNav_v1.9_20160513T120611.xml
283C28901RF RadNav_v2.1_20170320T132115.xml
283C24890RF RadNav_v2.1_20170320T132115.xml
283C26774RF RadNav_v2.1_20170320T132115.xml
283C20959RF RadNav_v2.4_20171019T133638.xml
283C21455RF RadNav_v2.4_20171019T133638.xml
280D80660RF RadNav_3.X_v3.3.xml
280D80700RF RadNav_3.X_v3.3.xml
280D84804RF RadNav_3.X_v3.3.xml
280D87300RF RadNav_3.X_v3.3.xml
280D88224RF RadNav_3.X_v3.3.xml
283C26365RF RadNav_3.X_v3.3.xml
283C22026RF RadNav_3.X_v3.3_20180730T152834.xml
283C24791RF RadNav_3.X_v3.3_20180730T152834.xml
283C27999RF RadNav_3.X_v3.3_20180730T152834.xml
283C29310RF RadNav_3.X_v3.3_20180730T152834.xml

So you may select appropriate left number in the all_vin file and send it to the bot together with your vin

Regarding the wifi ELM I need to look at the elm log before suggest you anything.

[crs-ica]

These are the results of the update and the partial conclusions:

1. Problems related to configuration (missing ESE activation, CAN multiplex errors, wrong car pictures in multisense, etc) are all solvable with lot of attention and coordination between MICOM version, main user app version (v2, v7, etc) and ecu xml files used to read/write data through CAN bus.
   In my case, the config file generated with the code from @shrlnm (Thank you for giving me that hint!) (see the discussion above) proved to be slightly different than the original one and in consequence than the original main app v2 (for example had SPVR parameters present for use with app >v2 also had an extra byte for the ECU config - the problem with the wrong car picture and other few minor tweaks).

2. Usually, the unit config parameters remain unchanged when updating the main app (v7 -> v9). I suspect that when doing the initial update v2 -> v7 from different reasons (MICOM update maybe, unfortunate change in the geometry (map) of parameters, or a faulty cable connection, elm, etc) there is a chance of parameters alteration (this was my case). Be patient and verify each and every field by comparing (use pyren for safest results) your unit present data with what should be (from bot generated config file for example).

3. Even I had MICOM 5615 and main app v7 and I was using pyren in cmd mode I had moments when writing something on CAN and then reading something else back or writing something on CAN and the developer mode on the unit said otherwise or having different read results on CAN vs developer mode. Because I don't know at the moment the exact datapath of the config parameters through the system from CAN /main app to memory, I don't have a strong opinion on that mater and I can only say again: check every action you do and try to minimize the changes every time to easily identify an error. Also this behavior could be related to the next point.

4. After update to v7 (first v8 then downgrade to v7) the system seemed very laggy and unresponsive. Everyone is telling that this is due to hardware limitation (eg. CPU, video processor (say what?!!), and other voodoo but unknown! hardware differences). From the documentation I have (incomplete but still):

• LANR14 HW 1.1 has ARM Cortex-A9 Dual Core @1.00GHz, 1GB DDR3 @667mhz, 32 GB eMMC
• LANR16 HW 2.0 has ARM Cortex-A9 Dual Core @800mhz, 1GB DDR3 @528MHz, 32 GB eMMC
  so in my eyes HW 2.0 is the same or so (slightly less power but the unit doesn't have a fan anymore for example) with HW 1.1.
  After some days of searching and debugging I discovered that in my installed v7 (path: developer mode/settings app/aps/in use aps) the operating system has available 0.5 GB of DDR with only 20-30 MB free and numerous apps signaling that they will restart. This was the moment I suspected it could be an OS problem of not addressing the entire memory (it happened once to me also in our developed systems - one cfg file wrong and goodbye half of your available DDR). I don't know if this is a general problem, if it was related only to my unit or if my v7 update file was somehow incomplete.
  After this discovery I have updated the system to v8 with the same disappointing result and -----> then to v9 were to my surprise, the RLink is again in his best days :)). Inspecting the same menu I found now that I have 600 MB occupied RAM and 300 MB of free RAM totaling 1GB DDR.
  So, if you have a LANR14 HW1.1 maybe it is worth checking how much DDR your OS sees.

@shrlnm thank you again for your earlier reply. I will figure out how to work with doc_maker.
Is this log file ok?
elm_log.txt

[shrlnm]

@crs-ica the log is good enough for your windows OS.

[shrlnm]

@crs-ica just for reminder. When you have micom 5615 and LGU 8 or 9 you should not do any configuration thru the CAN especially audio parameters as it lead to broken audio. For recovery in such situation you will have to rollback to v7, virginize and configure the box from the scratch

[crs-ica]

@shrlnm

1. I have just updated the RS monitor field with a custom Pyren macro. I saw no problem with that address on CAN. Do you know a specific address or part of the RLink memory map that cannot be accessed correctly on CAN (having v8,9 app version combined with micom 5615).
   Also, do you happen to know if somehow the developer mode also cannot correctly acces parts of config memory?
2. When closing a connection with Pyren I see this log:

RESETTING ELM

ERRORS STATISTIC

error_frame = 0
error_bufferfull = 0
error_question = 1
error_nodata = 0
error_timeout = 0
error_rx = 0
error_can = 0

RESPONSE TIME (Average)
response_time = 0.006

The "# * error_question = 1" should pose a problem? Where I can find more details about it?

[shrlnm]

@crs-ica

1. Actually the problem is that the micom module and the android have their own storage for the parameters. When you send a CAN command, the micom receive it, check the length and field values, response you with OK, and safe in their flash. Then it sends the same data (with the same binary structure) to the android, but the android are waiting the data in their own format, and you can't influence on this process if the lenth of the micom representation and the android represantation are different. You may just compare xml files from the ddt database.
   Also different LGU versions treat some parameters in a different ways. For example, some parameters are mandatory in v7 and optional in v8/v9. You may check it by generating autoconfig with a bot for different versions.
2. @KarelSvo answered you.

[crs-ica]

I understand the mismatch between the MICOM format and Android format for CAN messages.
I was interested to know if there are known addresses with changed data format for v8, 9 vs v7 (and MICOM 5615) or I should just compare different xml files (for example v2.x with v3.x) and extract from there possible changed addresses.

Later edit:
On the other side I am not so convinced that Android has his own cfg storage that can be accessed without data format issues because I tried to modify from developer mode some parameters and I didn't had always the expected result. And this happened even with MICOM 5615 and LGU v7.
I don't have the schematics (are there any schematics for this piece of hardware?) but it seems that reading and writing from LGU is also passing through MICOM (or so it seems judging from the behavior).

[shrlnm]

DiagRW tool is like a rudiment. Not sure that someone modify it for new versions.
It modify files in folder /virgin/configuration You may decompile it and look inside
You will find here something like this

   static {
        FILE = new File("/virgin/configuration/GEN1_1");
        DEFAULT = new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
    }
    
    public Diag_Gen1_1() {
        this.Adapter = null;
        this.mHandler = new MyInnerHandler(this);
        this.ClusterSkinChoice = 0;
        this.UnstableTrajectoryAlert = 0;
        this.SteeredWheel = 0;
        this.SED = 0;
        this.ANC = 0;
        this.RearCAMGuidelineSetting = 0;
        this.VehicleLength = 0;
        this.VehicleWidth = 0;
        this.VehicleHeight = 0;
        this.AxleDistance = 0;
        this.AxleLengthFront = 0;
        this.AxleLengthRear = 0;
        this.CarType = 0;
        this.DF_SkinChoice_Eco = 0;
        this.DF_SkinChoice_Comfort = 0;
        this.DF_SkinChoice_Normal = 0;
        this.DF_SkinChoice_Dynamic = 0;
        this.DF_SkinChoice_Perso = 0;
        this.DF_MexSwitch_IntensityWithoutAmbient_lighting = 0;
        this.CF_MexSwitch_Type = 0;
        this.CF_DualMode_Mgt = 0;
        this.CF_Preferential_Mode1 = 0;
        this.CF_Preferential_Mode2 = 0;
        this.DF_ESESoundActivation_Eco = 0;
        this.DF_ESESoundActivation_Comfort = 0;
        this.DF_ESESoundActivation_Normal = 0;
        this.DF_ESESoundActivation_Dynamic = 0;
        this.DF_ESESoundActivation_Perso = 0;
        this.DF_ESESoundType_Eco = 0;
        this.DF_ESESoundType_Comfort = 0;
        this.DF_ESESoundType_Normal = 0;
        this.DF_ESESoundType_Dynamic = 0;
        this.DF_ESESoundType_Perso = 0;
        this.GNSS = 0;
    }
    
    private void readData() {
        final ReadThread readThread = new ReadThread(this.mHandler, this);
        readThread.setDaemon(true);
        readThread.start();
    }
    
    private void saveData() {
        this.updateData();
        try {
            File_util.saveFile(Diag_Gen1_1.FILE, 0, 25, this.buf);
        }
        catch (FileNotFoundException ex) {}
    }

[crs-ica]

Interesting. I have used it to at least read the parameters and it seemed to me that the menus are different between v2 and v7 or v8,9.
In general, the differences seem to follow the radnav xml content. The newer LGU versions have new pages and so on.
Can you give me a hint of how to start with decompiling it? Thank you!

[shrlnm]

@crs-ica first unpack lgu with lgu tool
from msieurlolo_fr or binwalk or similar tool
then find a partition with app folder. There are all tools in format of odex
convert any interesting tool from odex to dex with any deodex tool
then convert dex file to jar. I use dex2jar
Then the jar file may be opened with any java decompiller, Luyten for example

May be I wrong and DiagRw is not a rudiment. I did non compare the code from different versions but there are a lot of complains from different people on it. I prefer to change the configuration thru the CAN

[KarelSvo]

The "# * error_question = 1" should pose a problem? Where I can find more details about it?

No problem if it's the missing answer to STI is.
https://gitlab.com/py_ren/pyren/-/blob/master/pyren/mod_elm.py?ref_type=heads#L581
A test, to see, whether an STN chip based interface is connected.
Or no response to STP53, test STN interface with 2 Can modules.

[Zener-hub]

@crs-ica Hi, How did you update ICOM from 4992 to 5615? can you explain please? I bricked my R-Link 2 while trying to upgrade from 2.2xx to 3.3.xx without updating ICOM. Do you have any options to recover it? Thank is advance.

[crs-ica]

The update was done with Clip and with specific firmware file. I don't have those. And I don't know were to find the MICOM firmware. I am sorry for not helping you with my answer.

[Zener-hub]

Thank you very much for quick response. I think I have to go to dealer if I wanted to get it re activated. BTW you have read/write experience of the EEPROM of R-Link 2 I guess? Any input will be highly appreciated as I am thinking ok replace the dead unit with used one from ebay.

[crs-ica]

All I can say is that you need lot of time and attention to details. There is no simple solution because writing/reading parameters through CAN with different MICOM and/or LGU versions gives you a mixed bag of results.