Hacking with HEW

dschultz · **Posted:** Fri Jan 06, 2012 12:55 am

I tried your project from the first post in KE (KPIT-Eclipse) and it appears to compile. I can get the Debugger/Simulator started too. But I can't figure out how to get it to do a "CPU Reset" to load the correct pointers. And I still need to figure out how to define a RAM section in KE.
gdb (sim) shows the correct addresses...
Here's the output from the commandline version of the simulator.

Code:

C:\Program Files\KPIT Cummins\KPIT-Eclipse\GNUSHv11.02-ELF\sh-elf\bin>sh-elf-gdb.exe \workspace\KPIT\EcuHacks2\Debug\EcuHacks2.x
GNU gdb (GDB) 7.2.50.20101207
Reading symbols from \workspace\KPIT\EcuHacks2\Debug\EcuHacks2.x...done.
(gdb) target sim
Connected to the simulator.
(gdb) load
Loading section .vects, size 0x400 vma 0x0
Loading section .text, size 0x8ac vma 0x1000
Loading section Misc, size 0x408 vma 0x18ac
Loading section .Metadata, size 0x30 vma 0x1cc0
Loading section RSTHandler, size 0x30 vma 0x1cf0
Loading section RevLimitPatch, size 0x4c vma 0x1d20
Loading section RomHole, size 0xcc vma 0x1d6c
Loading section .rodata, size 0x290 vma 0x1e38
Loading section .data, size 0x10 vma 0x20c8
Start address 0x17d0
Transfer rate: 42592 bits in <1 sec.
(gdb) b main
Breakpoint 1 at 0x1004: file ../src/EcuHacks2.c, line 41.
(gdb) run -v
Starting program: \workspace\KPIT\EcuHacks2\Debug\EcuHacks2.x -v

Breakpoint 1, main () at ../src/EcuHacks2.c:41
41          }

(gdb) info reg
r0             0x0      0
r1             0x1000   4096
r2             0x80000  524288
r3             0x0      0
r4             0x0      0
r5             0x0      0
r6             0x0      0
r7             0x0      0
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
r13            0x0      0
r14            0x2ffffc 3145724
r15            0x2ffffc 3145724
pc             0x1004   4100
pr             0x17e0   6112
gbr            0x0      0
mach           0x0      0
macl           0x0      0
(gdb)

nsfw · **Joined:** Thu Nov 23, 2006 2:23 am **Posts:** 2565

dschultz wrote:

I tried your project from the first post in KE (KPIT-Eclipse) and it appears to compile. I can get the Debugger/Simulator started too. But I can't figure out how to get it to do a "CPU Reset" to load the correct pointers. And I still need to figure out how to define a RAM section in KE.

In HEW the Debug menu has a "Reset CPU" item. However it doesn't reset all registers - I think all it does is reset PC to 0xA0000000, which is the _ResetHandler function in ResetHandler.s.

If you manually set PC to that address, I have a "mov.l Stack,r15" instruction to initialize the stack pointer, and a call to SetValues (a C function in EcuHacks.c) which sets a few values in RAM. The rest of the code makes no assumptions about any registers or RAM being initialized.

HEW also has a Setup menu with a System sub-menu with a "Memory Resources..." item that brings up a dialog box that you can use to define RAM.

nsfw · **Joined:** Thu Nov 23, 2006 2:23 am **Posts:** 2565

Z0rr0 wrote:

Attached.

Stumped.

dschultz · **Posted:** Fri Jan 06, 2012 1:49 pm

NSFW wrote:

In HEW the Debug menu has a "Reset CPU" item. However it doesn't reset all registers - I think all it does is reset PC to 0xA0000000, which is the _ResetHandler function in ResetHandler.s.

Yup, I ended up doing that manually and it starts to step through the code as you would expect.

NSFW wrote:

HEW also has a Setup menu with a System sub-menu with a "Memory Resources..." item that brings up a dialog box that you can use to define RAM.

This part I still need to figure out. gdb creates sections based on the code but I think I still need to create the RAM section. The mem statement in gdb seems like it should do that but I've had little luck with it so far. I get a segmentation fault when I get to a statement that tries to write to RAM like saving to the STACK.

BTW: In HEW, why did you choose SH-4 rather than SH-2E? The 7058 processor is of the later.

Z0rr0 · **Joined:** Tue Nov 14, 2006 6:05 pm **Posts:** 63

NSFW wrote:

Z0rr0 wrote:

Attached.

Stumped.

i took just the SD ecuparams out of your XML file, and put them into my logger-orig..
i attached it, but i have not tested it. i will during my lunch hour.

Z0rr0 · **Joined:** Tue Nov 14, 2006 6:05 pm **Posts:** 63

Z0rr0 wrote:

NSFW wrote:

Z0rr0 wrote:

Attached.

Stumped.

i took just the SD ecuparams out of your XML file, and put them into my logger-orig..
i attached it, but i have not tested it. i will during my lunch hour.

most everything works.
I cannot select "Intake Air Temperature" or "Manifold Relative Pressure (Corrected)"
But it seems that I can use SD Temp and SD Pressure instead.

i'll do some logging tonight, and see if i can figure out the idle and cruise tuning, but that stuff i'll post in the 32-bit Speed Density thread.

nsfw · **Joined:** Thu Nov 23, 2006 2:23 am **Posts:** 2565

dschultz wrote:

BTW: In HEW, why did you choose SH-4 rather than SH-2E? The 7058 processor is of the later.

Yikes. That was a mistake. Fortunately I seem to avoided doing anything that isn't compatible.

Thanks for pointing that out.

nsfw · **Joined:** Thu Nov 23, 2006 2:23 am **Posts:** 2565

Zorro noticed the the VE logging parameter didn't match up with the numbers in his VE table.

There was a bug in the scaling for the table - this is the correct scaling:

Code:

   <scaling name="VE(%)" units="VE(%)" toexpr="x*.0000457763672" frexpr="x/.0000457763672" format="%.2f" min="0" max="2" inc="0.025" storagetype="uint16" endian="big"/>

The only change is the constant in the to/from expressions.
The value in the file that I posted earlier was from Freon's original definition XML.
The .0000457763672 value matches the constant that is being used in the patch.
I should have double-checked that, especially since Merp mentioned that he'd changed it.

Anyway, after making this change, the percentages shown in the VE table will appear quite a bit smaller (almost halved), and they they will match the actual VE percentages that the ECU is using (which the logger is already reporting accurately).

I'm working on an update to the patch that will include an atmospheric pressure compensation, and fixed XML for the VE table. If any other LGT'ers out there are planning to try SD soon, I suggest waiting for the next update. It should be ready next weekend at the latest, probably sooner.

The next one will be compiled for the correct CPU architecture, too. :oops:

Z0rr0 · **Joined:** Tue Nov 14, 2006 6:05 pm **Posts:** 63

I'm glad i could help with the process.

:mrgreen:

td-d · **Posted:** Mon Jan 09, 2012 12:37 pm

NSFW / Merp - just to double check, in the defs that Merp posted and Martin is using the scaling is x*.00007629 (half of Freon's constant). I assume you did this to make the values appear more realistic Merp?

The .0000457763672 that is in the VE table as the multiplier - this is the original multiplier that would have to be multiplied by 1.3, correct? I'm getting my head twisted up as to whether it's the constant or the table multiplier that needs to be increased by 30%...

nsfw · **Joined:** Thu Nov 23, 2006 2:23 am **Posts:** 2565

The value in the XML affects the presentation of the table in EcuFlash, but not the execution/evaluation on the ECU. The value in the XML must match the value in the table definition.

The 1.3 multiplier in the code affects the ECU, but not the presentation of the table in EcuFlash. However it makes the values in the table more believable.

Merp · **Joined:** Thu Jul 23, 2009 5:46 pm **Posts:** 863

Those scalings are the gradients for the table data, to convert from 16 bit unsigned integer to a meaningful value.

I'm going to have to check on that scaling I had posted, but It doesn't look right :shock:

uint16 with range 0-1.5 should be 1.5/32768 = 0.0000457763671875

I've updated this value in my SD rom post

td-d · **Posted:** Tue Jan 10, 2012 9:24 am

NSFW wrote:

The value in the XML affects the presentation of the table in EcuFlash, but not the execution/evaluation on the ECU. The value in the XML must match the value in the table definition.

The 1.3 multiplier in the code affects the ECU, but not the presentation of the table in EcuFlash. However it makes the values in the table more believable.

Yeah - the XML defs are only for viewing the 16 bit data in the actual table in a meaningful manner (and should match the table multiplier) - what I'm getting confused about is, to deal with the +- 30% too lean AFR without having to tweak the injectors - is it Freon's multiplier in the code that needs to be multiplied by 1.3 or the table multiplier? Freon's constant I assume...

EDIT - I think I'm being blond. By editing the incorrect table scaling, the VE tables basically drop by half, which means raising the entire value of the table by 1.3 still gives you realistic values, and within the 0-1.5 range - in other words, there's no need to fiddle with the multiplier at all.

Merp · **Joined:** Thu Jul 23, 2009 5:46 pm **Posts:** 863

Exactly, you only need to change the SD constant if the ROM table values are approaching their limit. Iirc, h'7FFF for unsigned 16bit int, and d'1.5 after gradient/offset for this particular table.

nsfw · **Joined:** Thu Nov 23, 2006 2:23 am **Posts:** 2565

NSFW wrote:

The next one will be compiled for the correct CPU architecture, too.

Well that was plan. There's more to it than I thought, and I'm stuck.

I changed the compiler and simulator to use SH-2E rather than SH4, and moved the ResetHandler code to 0x4000 and things seem to work just fine at first... The stack pointer gets set, and the CPU does a jsr into my SetValues function, which sets values in RAM as expected... but then the simulated CPU doesn't rts from SetValues.

Instead, when it gets to these last few instructions in SetValues (shown below), after executing the "mov R14,R15" the PC register is set to the NOP instruction - it skips "mov.l @R15+,R14" and the rts instruction (PR is pointing to the correct return address, so rts should just work). And then it starts executing the byes that follow - bytes that contain addresses of RAM locations and the constants that the SetValues function was storing in those locations.

Code:

MOV.L     @(H'0040:8,PC),R1
MOV.W     @(H'0008:8,PC),R2
MOV.L     R2,@R1
MOV       R14,R15          - this executes
MOV.L     @R15+,R14        - this is skipped
RTS                        - this is skipped
NOP                        - this executes, and the bytes that follow it also get executed

WTF? Help?

RomRaider

Hacking with HEW

Who is online