Has my GQ-4X died?

[Charlescrown]

This is the scenereo.

I did a log to do some tuning and went and read my existing bin file to make sure I was working with the latest one.
When I read the file in Tunerpro it showed crazy values in all the areas where input is done. Example all the timing data is all 89.65 degrees and the VE is all 99.61
I tried another cable. Didn't fix it.
I loaded an older bin file. Reads fine in Tunerpro.
I downloaded the lall. Didn't fix it.ates Tunerpro. Didn't fix it.
I tried another computer. Didn't fix it.
I tried reading another memcal. Same result crazy numbers.
I used another XDF form my files. Didn't fix it.
I'm not game to load what I think is my last bin file in case it crashes my memcal.
My conclusion is the reader. I did try a few Mcumall software versions but no good with any.
Windows 7 so no updates could have caused my problem.
I rebooted my laptop multiple times and unplugged the reader but I have run out of things I know may cause the problem.
Spent all day now with this frustrating thing and at wits end.
Opinions. Do you think the reader has crashed?

[antus]

When you read of the nvram you get a different view of the world to when you read over ALDL. I'll work in bytes. The nvram chip is 128K. The PCM is an 8 bit processor that can see 64K. OSE 12P is 32k.

When you have a stacked bin you get:
0x0000 32k blank | 32k 12P | 32k blank | 32k 12p 0x1FFFF

When you read over ALDL you see only the first half or only the second half so 32k blank (technically has some ram as well) then 32k 12p.

OSE Flash tool knows what is what and it'll read pcm range 0x8000-0xFFFF and save it to a 32K file. The XDF is setup for this file. So the bin should be 32k big, and you'll get it when you read over ALDL.

OSEPlugin also knows what is what. So when it sees the XDF and tunerpro ask for address 0x0000 it'll add the 0x8000 offset to hide it from you. So emulation works.

So it's all just different view of the world things. If you read the nvram, and are on MAP A and you have a way to chop up the 128k bin file you got from the GQ and take 0x8000-0xFFFF you'll get a 32K file that will work fine in Tunerpro with the 12P XDF.

But, its a lot easier to do a get bin over ALDL with oseflashtool.

If you need to recover you can write any of the 128K _stacked file to the nvram in the GQ, and put it in the car, then do a write cal with oseplugin to send the calibration back from your 32k bin over ALDL assuming 12P versions match between the bin and the car. Nearly all of them in the wild are v112. If you want to, you can power off and swap the map jumper then power on and send it again so you have the same base data in both maps. Then put the jumper back on and you are good with a working copy and a spare.

[Charlescrown]

The way I do it I use a flash 27sf512 and read write through the the GQ4X. I am running 12P and use 8000 offset. I don't use nvram I just log and make changes to then write the new bin file to the memcal. When I read the memcal the file views fine with the gq4x software because I can see the info at the end of the file but when I save it it has wild data everywhere. I think there is an issue when saving the bin file. Anyway today's a new day so I'll post up the outcome.

[antus]

512 will give you a 64k file, and you'll still need to crop out the first half of it to keep only the second 32k for it to line up with the xdf. your write offset is correct if it is working. I had trouble with using offsets and GQ but that was a very long time ago now and I dont know if that is fixed or not (could be your problem with save, too). if you can avoid offsets that is better. I'll ask an AI to give you a powershell script that can crop out the second half of a 64k file in to a 32k file so you can read, save, crop and see how you go.

save this to binsplit.ps1

Code: Select all

param (
    [Parameter(Mandatory = $true)]
    [string]$InputFile,

    [Parameter(Mandatory = $true)]
    [string]$OutputFile
)

# Constants
$chunkSize = 32KB
$totalExpectedSize = 64KB

# Validate input file exists
if (-not (Test-Path $InputFile)) {
    Write-Error "Input file does not exist."
    exit 1
}

# Validate file size
$fileInfo = Get-Item $InputFile
if ($fileInfo.Length -ne $totalExpectedSize) {
    Write-Error "Input file must be exactly 64 KB. Actual size: $($fileInfo.Length) bytes."
    exit 1
}

# Open file streams
$inputStream = [System.IO.File]::OpenRead($InputFile)
$outputStream = [System.IO.File]::Create($OutputFile)

try {
    # Skip first 32 KB
    $inputStream.Seek($chunkSize, [System.IO.SeekOrigin]::Begin) | Out-Null

    # Read next 32 KB
    $buffer = New-Object byte[] $chunkSize
    $bytesRead = $inputStream.Read($buffer, 0, $chunkSize)

    if ($bytesRead -ne $chunkSize) {
        Write-Error "Failed to read the expected 32 KB from input file."
        exit 1
    }

    # Write to output file
    $outputStream.Write($buffer, 0, $bytesRead)
}
finally {
    $inputStream.Close()
    $outputStream.Close()
}

Write-Host "Successfully wrote second 32 KB to output file."

run powershell and use it like this to cut down a 64k file to 32k keeping the top half.

Code: Select all

.\binsplit.ps1 -InputFile "input.bin" -OutputFile "output.bin"

[Charlescrown]

I know about the offset that's why I have an 8000 start address and that works fine giving a 32kb file. I found an older memcal setup so played around with that. I got the last bin file I had written and loaded it and it works fine so my guess is there is an issue reading the eprom. The car runs fine but if I try to read it all I get is the garbles mess. I can delete and rewrite fine. Maybe I never found it before because it's been a long time since I actually read one. Found another issue with Tunerpro. Same version one windows 7 the other windows 11 and it will not show a view of the Data Monitors. Same version, same XDL and same log. Works fine with windows 7 but not 11 I don't think their keeping pace with windows. Maybe the problem is staring at me.

[vlad01]

If you view what it pulled in the hex view, you can become familiar with the patterns of data. You can open a known good file and have a bit of a look, and then do the same with what the programmer pulled off the chip, you'll see there is two lots of what the normal unstacked bin has. But if none of the patterns look anything alike, it could be pulling gibberish.

Things to look out for is a bad connection on one of the chips address pins in the zif socket, this will make the data look scrambled from the programmer accessing the wrong areas for what address it thinks it's reading or missing data on that row/column etc...

Not a programmer fault, but I once had a chip that had an internal fault that causing it to write the same data starting in two addresses simultaneously, I suspect it was an internal short, it always errored once the lower address crashed into the random upper address that it already had written, much like a game of tetras when they pile up and you run out of space to move.


Some fault in the programmer might be causing some weird issues as you describe, but not a given until all other possibilities are rulled out.

Also, double check the device in the program is set correctly, as it might be reading it as a different device and assuming the data is laid out or read in a certain way electrically and not actually how the chip needs, giving rise to gibberish even though nothing is physically wrong.


Lastly, yes it is possible the GQ4x is dead, I know quite a few of us members reported ours dying over the years, mine died the xmas prior without warning and I was disappointed that I only got maybe 50 cycles, if that, out of it despite it's age.

I got the China T48 and love it! way better in every way, way cheaper, quick availability, much smaller, nicer looking, wider range of adapters and supported devices out of the box, much better driver and software support, same familiar if not slightly easier UI. Worked perfectly on my PC our of the box where as my GQ4x needed to run in compatibility mode, drivers that were manually forced installed and a broken GUI that glitched on 10 and 11 and looked straight out of win 3.1. The T48 had none of those issues and even worked on my Linux laptop with a win 7 VM right out of the gate, USB port had no issue with the drivers under the VM where I struggled to get them to work natively on the GQ in windows sometimes.

So even if it has really died, you'll be happy with the other options out there and I can vouch for the T48.

[Charlescrown]

Thanks for the info on that reader. They look good. The thing I hate abt the Mcumall is the difficulty sorting out what software and drivers to use. I did have it working on my old pc with windows 10 but not with any of their drivers. I did find one but the access to it has been taken down. I have been having trouble with it for some time so maybe it's time to update. I went to their website and see that there is a new model out so I'll do some research.

[Ken]

I did find one but the access to it has been taken down. I have been having trouble with it for some time so maybe it's time to update. I went to their website and see that there is a new model out so I'll do some research.

I have everything saved from the sight as the uploads/drivers were hosted, if you want I'll send them to you.

[antus]

The driver is here https://www.mcumall.com/downloads/ use "Signed GQ USB 2.01 driver for GQ-4X, GQ-5X 07-10-2015 This is a Signed version driver for Win 8/8.1, Win 10. Thanks to GB who provided this signed driver."

It doesn't mention 11 but it believe it also works there. They have an unsigned one for win 7 but I'd probably lean to this one and expect it's likely to work on 7. In general signed drivers sure beat unsigned and the hurdles we used to have to jump through.

[Charlescrown]

Thanks for the offer Ken but if and when I get it working I still have this funny issue with tunerpro.
Tried that one antus but when I tried to update the driver in device manager it says cannot find driver which I know the address where it is is correct. I have it all working on my old laptop windows 7 but it's so slow so at least I can still tune. I'll retry reading the eprom again and see what I get.