Pages: [1]
Author Topic: Creating multiple TVLDMX in MED9 for big turbo boost setup  (Read 4787 times)
jacktfsi
Jr. Member
**

Karma: +18/-0
Offline Offline

Posts: 44


« on: January 08, 2021, 04:30:19 PM »

Hi Nef, i've recently created a map switching routine switching ldrxn on med9.1 (edition 30 golf) using basanos method (Thanks!) and i'm putting a big turbo on the car soon so thought it would be easy to get all the data for setting up the boost by creating multiple TVLDMX's then just switching them from the CC and Brake pedal when wanting to switch between maps. (instead of using KFLDRAPP and flashing 5-6 different maps each at 12 min write speed.)

I've already written the code for the map switching but i've never created extra maps so i was just wondering if i've done it correctly? If so then hopefully this can help someone else.

I first found the address of TVLDMX in my bin @1CFA38 then added the offset 0x400000 = 5CFA38
This took me directly to the place that stores TVLDMX so i then cross referenced the address and found where i was being used.

It was being loaded at 0044EA2C so i added my branch just before this to my map switching code.

Original code:

 ROM:0044EA14 # ---------------------------------------------------------------------------
ROM:0044EA14                 lbz       r12, byte_7FEC7F
ROM:0044EA18                 cmpwi     r12, 0
ROM:0044EA1C                 bne       locret_44EA6C
ROM:0044EA20                 lbz       r12, byte_7FEC80
ROM:0044EA24                 cmpwi     r12, 0
ROM:0044EA28                 bne       locret_44EA6C
ROM:0044EA2C                 lis       r4, word_5CFA38@ha
ROM:0044EA30                 lhz       r4, word_5CFA38@l(r4)
ROM:0044EA34                 li        r11, 0x4E
ROM:0044EA38                 divwu     r3, r4, r11
ROM:0044EA3C                 lis       r4, 0 # 0xFFFF
ROM:0044EA40                 ori       r4, r4, 0xFFFF # 0xFFFF
ROM:0044EA44                 cmplw     r3, r4
ROM:0044EA48                 ble       loc_44EA50
ROM:0044EA4C                 b         loc_44EA54
ROM:0044EA50 # ---------------------------------------------------------------------------
ROM:0044EA50

New code:
0 locret_44EA10:                          # CODE XREF: sub_44A858+41ACj
ROM:0044EA10                 blr
ROM:0044EA10 # End of function sub_44A858
ROM:0044EA10
ROM:0044EA14 # ---------------------------------------------------------------------------
ROM:0044EA14                 lbz       r12, byte_7FEC7F
ROM:0044EA18                 cmpwi     r12, 0
ROM:0044EA1C                 bne       locret_44EA6C
ROM:0044EA20                 lbz       r12, byte_7FEC80
ROM:0044EA24                 cmpwi     r12, 0
ROM:0044EA28                 bne       locret_44EA6C
ROM:0044EA2C                 b         loc_47D46C
ROM:0044EA30 # ---------------------------------------------------------------------------
ROM:0044EA30                 nop
ROM:0044EA34
ROM:0044EA34 loc_44EA34:                             # CODE XREF: ROM:0047D490j
ROM:0044EA34                                         # ROM:0047D49Cj ...
ROM:0044EA34                 li        r11, 0x4E
ROM:0044EA38                 divwu     r3, r4, r11
ROM:0044EA3C                 lis       r4, 0 # 0xFFFF
ROM:0044EA40                 ori       r4, r4, 0xFFFF # 0xFFFF
ROM:0044EA44               


Now my branch is added this then goes to the map switching code which simply switchs the map depending on what value is stored in the byte i've created which uses the CC and brake pedal as an input to increase the value each time the CC stalk input is pressed and shows up as an RPM signal depending on what map im in i.e. 1000rpm = map 1 etc

So now onto creating the extra TVLDMX i will need for my routine. TVLDMX is a 16bit map so i designated 2 bytes a value in IDA (these can be changed later in winols for your duty cycle %) and used the same code to load the original TVLDMX. (See below)

ROM:0047D46C loc_47D46C:                             # CODE XREF: ROM:0044EA2Cj
ROM:0047D46C                 lbz       r10, byte_7FABF7
ROM:0047D470                 cmpwi     r10, 0
ROM:0047D474                 beq       loc_47D488
ROM:0047D478                 cmpwi     r10, 1
ROM:0047D47C                 beq       loc_47D494
ROM:0047D480                 cmpwi     r10, 2
ROM:0047D484                 bge       loc_47D4A0
ROM:0047D488
ROM:0047D488 loc_47D488:                             # CODE XREF: ROM:0047D474j
ROM:0047D488                 lis       r4, word_5CFA38@ha
ROM:0047D48C                 lhz       r4, word_5CFA38@l(r4)
ROM:0047D490                 b         loc_44EA34
ROM:0047D494 # ---------------------------------------------------------------------------
ROM:0047D494
ROM:0047D494 loc_47D494:                             # CODE XREF: ROM:0047D47Cj
ROM:0047D494                 lis       r4, word_5F0800@h
ROM:0047D498                 lhz       r4, word_5F0800@l(r4)
ROM:0047D49C                 b         loc_44EA34
ROM:0047D4A0 # ---------------------------------------------------------------------------
ROM:0047D4A0
ROM:0047D4A0 loc_47D4A0:                             # CODE XREF: ROM:0047D484j
ROM:0047D4A0                 lis       r4, word_5F0810@h
ROM:0047D4A4                 lhz       r4, word_5F0810@l(r4)
ROM:0047D4A8                 b         loc_44EA34
ROM:0047D4AC # -----------

So the new address's for TVLDMX 2 and 3 are 5F0800 and 5F0810. The code jumps here from the original code and picks an address depending on the value stored in the byte (1,2,3) this then loads the h and l halves with the values stored and then it branches back to the original code.


This is the code for the extra TVLDMX maps below, as you can see i've just used 2 bytes to stored data and this is then used to load the value stored in them to TVLDMX to be used to limit duty cycle.

I don't know if this is correct or if i've done this right but i'd love to hear from some more experienced guys on here to steer me in the right direction if what i've dones wrong and hopefully help anyone else who's planning similar.

ROM:005F0800 word_5F0800:    .short 0x2710           # DATA XREF: ROM:loc_47D494o
ROM:005F0800                                         # ROM:0047D498r
ROM:005F0802                 .short 0xFFFF
ROM:005F0804                 .long 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF
ROM:005F0810 word_5F0810:    .short 0                # DATA XREF: ROM:loc_47D4A0o
ROM:005F0810                                         # ROM:0047D4A4r
ROM:005F081

Cheers!
Logged
jacktfsi
Jr. Member
**

Karma: +18/-0
Offline Offline

Posts: 44


« Reply #1 on: January 09, 2021, 10:03:28 AM »

So adding my findings after testing this today.

I first figure out there was  2 places that the cross reference related to that used the TVLDMX address i.e. 5CF38A

Ori code below:

ROM:0051B66C # ---------------------------------------------------------------------------
ROM:0051B66C
ROM:0051B66C loc_51B66C:                             # CODE XREF: ROM:0051B660j
ROM:0051B66C                 addi      r31, r28, 0
ROM:0051B670
ROM:0051B670 loc_51B670:                             # CODE XREF: ROM:0051B658j
ROM:0051B670                                         # ROM:0051B668j
ROM:0051B670                 lis       r28, word_5CFA38@ha
ROM:0051B674                 addi      r28, r28, word_5CFA38@l
ROM:0051B678                 lha       r26, 0(r28)
ROM:0051B67C                 subf      r30, r30, r26
ROM:0051B680                 cmpwi     r30, -0x8000
ROM:0051B684                 bge       loc_51B690
ROM:0051B688                 li        r30, -0x8000
ROM:0051B68C                 b         loc_51B69C
ROM:0051B690


New code with branch added same as before with the other GPR that references 5CFA38, 5F0800, 5F0810:

ROM:0051B65C # ---------------------------------------------------------------------------
ROM:0051B65C
ROM:0051B65C loc_51B65C:                             # CODE XREF: ROM:0051B650j
ROM:0051B65C                 cmpwi     r28, 0x7FFF
ROM:0051B660                 ble       loc_51B66C
ROM:0051B664                 li        r31, 0x7FFF
ROM:0051B668                 b         loc_51B670
ROM:0051B66C # ---------------------------------------------------------------------------
ROM:0051B66C
ROM:0051B66C loc_51B66C:                             # CODE XREF: ROM:0051B660j
ROM:0051B66C                 addi      r31, r28, 0
ROM:0051B670
ROM:0051B670 loc_51B670:                             # CODE XREF: ROM:0051B658j
ROM:0051B670                                         # ROM:0051B668j
ROM:0051B670                 b         loc_47D4BC
ROM:0051B6


My code jumps to 47D4BC as described in the previous post and chooses the correct address depending on what you choose from the CC and B_br.

I've tested it today on the car and it works, heres some logs, map 1 is 100%, map 2 is 50% and map 3 0%.
Now i've proved it works im going to add 6.

Cheers.
Logged
jacktfsi
Jr. Member
**

Karma: +18/-0
Offline Offline

Posts: 44


« Reply #2 on: January 11, 2021, 02:58:39 PM »

So another update....

I've been trying to add 5x TVLDMX maps to switch via the CC and brake and have successfully managed switching 3 but when going to 5 using the same programming concepts just copy/paste and adding new address's i just keep bricking the ecu.

I've disassembled the code again and again and the code looks OK i believe but the only issue i might be having is writing too much code in one space? i feel the area may be used even though in IDA is FF'd. (i believe its the first bit of code which stores the can/cluster comms and checksum that may be the issue) - 0x47BD40

Ill attach my IDA project of the 5x tvldmx and also my .bin so someone on here that's a bit more experienced may be able to see a mistake or guide me in the right location?

 My code for map switching starts at 0x47BD40 (in IDA) - 0x07BD40 in the .bin and the TVLDMX map switching locations start at 0x47D46C (in IDA) - 0x07D46C

Cheers
« Last Edit: January 11, 2021, 03:02:05 PM by jacktfsi » Logged
jacktfsi
Jr. Member
**

Karma: +18/-0
Offline Offline

Posts: 44


« Reply #3 on: January 15, 2021, 11:37:43 AM »

Another update...

I've now got the 5 map TVLDMX switch working from the CC set button and brake pedal.

Would like to give a huge thanks to Basano for his help on reading the ram mirror and other questions i had.

My issue on the last bin was a branch address was wrong so it was branching to the wrong place in the ram and also i had set the counter to only see up to a value of 3 in the byte that stores the value for remembering the map switch so this needed changing to 4 so it could see 0->1->2->3->4

I've also attached my internal and external ram dump for a 115T file as this may help someone in the future.
Logged
prj
Hero Member
*****

Karma: +915/-425
Offline Offline

Posts: 5833


« Reply #4 on: January 16, 2021, 02:36:12 AM »

It is good that you are learning, but this is like doing dental surgery through the rectum.

The correct solution is to modify the binary and make a flash tool so that you can flash calibration changes only, bringing down the flashing time to <1 minute.
The less correct solution is to change a single variable - the axis on kfldrapp to read for example the cruise control mask instead of wped. Or ushk_w with a potentiometer also works.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
jacktfsi
Jr. Member
**

Karma: +18/-0
Offline Offline

Posts: 44


« Reply #5 on: January 16, 2021, 05:54:58 AM »

It is good that you are learning, but this is like doing dental surgery through the rectum.

The correct solution is to modify the binary and make a flash tool so that you can flash calibration changes only, bringing down the flashing time to <1 minute.
The less correct solution is to change a single variable - the axis on kfldrapp to read for example the cruise control mask instead of wped. Or ushk_w with a potentiometer also works.

That’s a good analogy! And I’d love to do that but I’m purely a hobbyists that’s interested in all this tuning but it isn’t my profession like most people on here so I’m just trying to find little ways to help me learn and also aid tuning somewhat - definitely not the best way to go about it but at least it’s helping me grasp the basics of ASM.

I’d love to be able to create a flash tool like you are mentioning but at the moment I’d say that’s most likely out of my league.

Great idea with KFLDRAPP too, so you could basically increment your duty based on the cc input which would bump you up each axis point?

Cheers!
Logged
prj
Hero Member
*****

Karma: +915/-425
Offline Offline

Posts: 5833


« Reply #6 on: February 01, 2021, 07:01:28 AM »

Great idea with KFLDRAPP too, so you could basically increment your duty based on the cc input which would bump you up each axis point?
Precisely. Resize the map to have everything covered.
If you want to be more advanced, make the axis a location in memory that gets incremented by 1 each time there is a leading edge on a CC input, and then gets wrapped back to zero.
Toggle between columns by pushing a button.
« Last Edit: February 01, 2021, 07:03:24 AM by prj » Logged

PM's will not be answered, so don't even try.
Log your car properly.
jacktfsi
Jr. Member
**

Karma: +18/-0
Offline Offline

Posts: 44


« Reply #7 on: February 01, 2021, 07:23:16 AM »

Precisely. Resize the map to have everything covered.
If you want to be more advanced, make the axis a location in memory that gets incremented by 1 each time there is a leading edge on a CC input, and then gets wrapped back to zero.
Toggle between columns by pushing a button.

That’s was my plan after you gave me the original idea - I’ll store the cc input to a byte in memory and every time it’s incremented it moves along the axis. I have already done the cluster comms so it displays my current map on the tach at 1,2,3,4,5krpm so will be easy enough to use this to visually see what axis location I’m at currently.

Cheers PRJ this was a very good idea
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.023 seconds with 16 queries. (Pretty URLs adds 0s, 0q)