RomRaider

Allright, just tried it out on my 02 wrx. Tested read, write, and ecu init and it works perfectly. I would recommend separating the beginning ecu response when reading from the actual ram dump. And adding the capability to dump to a file.

Also tried the logger and it displays the cal id properly. Not sure what other features were added to the logger than needed to be tested.

I'll see what I can do to let you save the read response to a file and also to allow you to filter out the response headers and checksums.

In the meantime you can always copy and paste the read responses to a text file manually.

Merchgod, is copying and pasting the dump into a text file easy for you to import into whatever tools you use or do you need the dump in a certain format? Like "08 ff 06" or "0a,ae,0f"?

text file is fine. I'm sure some of the ranges can't be read by SSM, so this will narrow it down.

Hmm read length of 1 worked (returned 4 bytes) but anything else for read length did not (I tried 32,64,etc). Am I doing something wrong? I dropped the MSB.

Sooo.... The size field, decimal or hex? I figure if I input the correct size and it might work next time. I'll try some later tonight. Off to werk!

Got a dump from an 05 sti (thanks crystal) and it looks like it won't dump more than around 250 bytes. For the 32bit ecus and RamTune, we need some big dumps, some as large 5kb or more.

Actually I think I tried 64 and up sizes which would be 256 bytes of data and more so that makes some sense. I'll try 1-62 as the size param (in decimal), but I won't have time tonight. It will have to be tomorrow night. I was able to read size=1 which gave me 4 bytes, so perhaps we just need a loop that reads 32 bytes at a time or just iterates through each address and pulls the 4 bytes at a time (for the 32 bit ECUs). Would be nice to have a range you can input in hex and it just reads through that entire range as well, but i can do the math instead, i am just lazy.

-Gabe

Crystal also said when reading the large blocks the DCCD and ABS light would come on. Similar to an issue that gabedude discovered when logging a large number of custom parameters (like 15+).

Thanks for the feedback guys. It has given me some ideas to improve the RamTune test app before another release. I have the following planned:

- save to file
- adjustable response timeout
- end address field (for reading ranges)
- a read loop for large ranges (above what range size should I start looping?)
- repsonse filter (to remove the header and checksum vales and display only the data in the response)

Anything else? If I add an end address, should I remove the length field, leave it, or change it to hex input?

Also, it would be cool to use this to change the rev limit on the fly or something else small and easily testable

I think I'm going to use this adjust my per gear wg compensation real-time.

I would just remove the size element and add the end address. Try looping every 100 bytes (0x64).

Can you make the block read/write size (in the loop) variable for 32 bit ECUs? Seems like size=62Decimal would be the max as that would give us less than 250 bytes.

Also, with the range and size question, could we have a switch:

Say starting address plus address offset in decimal (kind of like you have it, but it is labeled size right now). Then another set of input boxes with starting and ending addresses (in hex, 3 bytes is fine like you have it now, or just drop the MSB with an input of 8 chars). Two read buttons would be fine or a check box to choose which way to read.

Thanks.

-Gabe

This is fine with me as well instead of all my crazy requests. Whatever is easy.

When ever it gets ironed out, ill be glad to do some more dumps. The ABS light thing freaked me out for a second before I realized this had happened strangely enough when i was logging a good amount of parameters.