RomRaider

Put a couple of NOPs before using (RTS instruction ) updated stack pointer.

This processor uses pipelined instruction execution.

Yes, Section 8.8.5 of the SH-2E Software manual.

I've been doing some reading on C/C++ lately, and really dug into the latest HEW project today. I've got a good grasp on all the code, how each file works and interacts with other files, and how the pointers are set up. However, I could use some help with the HEW interface itself.

1. How does HEW interact with the full ROM file? I assume I need to add it somewhere or tell HEW where it is, downloads? What's up with EcuHacks2.x?

2. What windows/settings should be open/used while running a debug test?

Download the ROM module as a binary file worked for me.
.x is the debug executable file.

Thanks guys!

I'll try adding some NOPs tonight. This seems like something that the compiler should take into account, so I wonder if there's a checkbox somewhere that would get it to do that automatically.

And I'll have to print that section of the manual. I have a PDF of it but I basically just skimmed it and printed the list of instructions, and there's no hint of this in the section that I printed.

I thought that delayed branches were the only scenario for out-of-order execution... I had always thought of pipelining as a way for CPUs to execute carefully-ordered instructions faster, but had never guessed that it would lead to this sort of surprise when instructions are not ordered optimally.

EDITED FOR ACCURACY:
TWICE:

EcuHacks2.x is just the code in the HEW project. To test the interactions between SD and the stock ROM, you have to download a ROM that at least has the Pull2d hook applied to the stock 'get maf' routine. You can download freshly rebuilt versions of EcuHacks2.x over the top of the (not freshly rebuilt) ROM to get fast edit/compile/test turnaround times.

If you go to the Debug menu, there's a "Debug Settings..." menu item. That will let you pick the ROM file, and set the download order so that EcuHacks2.x downloads over the top of the ROM.

Usually I just have the project tree on the left (source files, download modules, etc) and the CPU register window on the right, and source code filling the rest of the window.

Occasionally I'll open a "memory" window to verify that things are being written to RAM correctly, and I'd advise doing that to begin with because it will indicate whether you have the simulator's RAM configured correctly. You should see mostly 00s, not FFs, in the 0xFFFF0000 - 0xFFFFFFFF range.

Are you downloading the ROM first then your compiled hack? If so, then is your hack located in the correct area of memory such that it is not overwriting part of the ROM that is important and picking up instructions from the ROM that should not be present?
I get to here and the next instruction causes an "Exception Error/Address Error" in the Debugger.

Thanks! I never noticed the debugging info in the output window before.

That helped me narrow it down to this line of C code:



Which is these three asm instructions:



The "MOV R14,R15" appeared to execute after those, which had me thinking that the problem was in that instruction or something after it, but in fact it's the final stages of "MOV.L R2,@R1" that cause the problem. MOV.L is for 4-byte values but R2 is not aligned on a 4-byte boundary.

Wrong:



Right:



So I'm moving forward again...

Thanks again for all the help, everyone.

I updated the post about downloading EcuHacks2.x and patched ROMs. For testing the SD stuff, it's essential to have a patched ROM, and I had kinda forgotten about that. But even the 'unit tests' for SD will call into the ROM code (outside of EcuHacks2.x) to verify that the ROM code can properly call into (and return from) the patch code.

I did a lot of early LC/FFS and SD testing without using a patched ROM, but at this point it's essential. I'll post another complete HEW zip before I go to bed tonight.

OK, this now builds with the SH2E compiler and all tests pass. If you set a breakpoint on the 'nop' in the TestFailed function in TestUtilities.c, it should get hit exactly once - there's a test that fails deliberately just to prove that failing tests will hit that break point.

There's a TestRom directory under the EcuHacks2 project which contains an unmodified ROM and a batch file to create a patched ROM using the latest build of the HEW project.

Don't anybody flash this just yet. I still want to give it another once-over first.

As I was trying to fall asleep last night (or this morning) I was starting to think that there was an alignment problem, glad you found it.

Got most of my programming mode & CEL flashing stuff written up in C++

Running into an issue with RomPatch. I have added a couple new sections and files for my code. I got everything to compile, then added patches to metadata.s. When adding the latest patch, I started getting System Exception: Internal Error in TryReadPatches: Patch is null. To rule out bugs in my code or sections, I commented out the first patch in metadata.s (known to work and patch) and the latest patch works fine. Seems like there is some kind of limit causing it to break.

As a workaround, I just moved the sub-sections of two patches into a single section.

Some more questions:

I'm trying to use character arrays to set value limits and default values of programming menu items. I was also trying to declare/init few arrays of selectable rev limiter values. Even specifying const on the array, it still loads every value of the array into the stack wasting a ton of cycles. Is there a way to declare/init them that will simply throw them in the data segment or do I need to include them in an assembly file?

Is there a better way to implement *pCurrentValue? Currently I'm just setting it to a base, then adding the CurrentMenu each time it runs. Array of pointers? I don't think it's a big issue because this code only executes during programming (engine off), but it never hurts to learn the right/other ways.



Also, I'd like to streamline the porting process, and my code uses a ton of new RAM params that once tested will never be necessary for logger defs. When I was using ASM, I would just define a base in the data segment and use offsets: mov.b @(0x2,r3),r0 with a comment of what it was.

Do you foresee any issues with something like this? From what I understand, #define just copies the right side at every occurance of the left.

Note that if we were writing an app for Windows or iOS, I'd just suggest turning on all of the compiler optimizations, and stop looking at the assembly code. But, since we're patching our code into Denso's...

I think that anything that's going to go into a table definition should be declared globally (outside the function). That will allow you to skip the step where values get copied into stack memory. That also makes it possible to write self-test code that refers to those values, and it gives you more control over how the values are laid out in the ROM. I actually made a similar change to my LC/FFS code for those two reasons. I'll post my current project in a minute.

I think the #define stuff should work. The preprocessor will recursively expand the macros, so you'll get something like "0xFFFFDERP+1+1+1" and I'm pretty sure that either the preprocessor or the compiler will turn that into "0xFFFFDERP+3" but you should double-check that.

Or maybe not... I think I have a better idea. I haven't tested this yet so it might need some tweaking, but I'm sure we can do something like this to solve the same problem with less effort:

Put these in a header file:



And in your code:



This way you only need to define one RAM address. You tell the compiler that there's a structure at that address, and you use the "->" operator to refer to fields inside the structure. The compiler should handle the rest.

When RomPatch printed that error, I think it was looking for the 0x12340002 or 0x12340003 value that indicates the start of a new patch in the Metadata segment, and it didn't find either. If you post a copy of Metadata.s I'll be happy to take a look.

I've attached a zip of my current HEW project. It's still just LC/FFS and SD, but the SD patch now has an atmospheric pressure compensation table. I've also done a bit of re-arranging to make things easier to maintain. The LS/FFS patches have three segments, one for tables (stuff that will go into definition XML), one for logic, and one for an "end marker" that goes into Metadata.s by name. This way I can add new tables without invalidating old table XML, and I don't have to manually adjust the end-address of the segment in metadata.s.

One of the LC/FFS patches (the "hook" patch) still needs literal start and end addresses in the metadata file but I have a couple ideas that might fix that.

There's also a couple new self-tests to make sure that the segments don't overlap, end addresses are higher than start addresses, etc.

I'm trying to minimize the number of manual steps that are required when making patches or editing them, and for the manual steps that ARE needed, I'm trying to get HEW to detect as many mistakes as possible.

Yesterday I flashed the patch from this version of the project and it seems fine other than the FFS rev limiter being too low. I'll start a thread in the SD base maps section with the patch itself.

I keep wanting to do one more little thing before I declare a release...

The attached zip file does the typedef struct thing that I mentioned earlier, so now only one RAM address has to be chosen, and the compiler does the rest. You still have to manually figure out the addresses for logger XML, but that's a lot less critical since errors in the XML will only break data logging. Human errors in choosing addresses could break motors, so I really like letting the compiler handle that.

It adds one or two instructions to each bit of code that reads or writes a memory location, but that's a small price to pay for getting rid of a whole class of potential human errors. And I have a hunch that even that will go away if I ever get the nerve to turn on optimizations - but for now I like the fact that the generated assembly code is really easy to understand and step through.