TH2830 vs TH2832

[nctnico]

@Josh: you are searching for text but what tv84 has altered is a single byte with the hexadecimal representation of an 8 bit number. 0xC0 = C0 (hex) = 1100000 (binary) = 192 (decimal)

But since you can't load a modified firmware, it looks like there is a checksum that is applied to the firmware chunks (which seems a pretty basic thing to do in order to make sure the firmware file hasn't been corrupted).

[KungFuJosh]

Considering that there's no other file, wouldn't the checksum value also need to be supplied by the firmware?

[tv84]

Looking at the code, it's easily visible that the "HW Version" is what I called, in my previous call-graph, the "Model Flag".

So your HW Version is 0xA7 which means it's a:

Ax - TH2830 / ST2830 / SM6023 / DHK6100 / JCX860 / TX6100 / TH7830 / TH2816D / OCT1010 / TH2830HY

[luudee]

Guys,

sorry, I have been very busy lately with work ...

But I would like to help, I have the TH2832 ...

What do you need ?

Cheers,
luudee

[tv84]

What do you need ?

Show me your HW version screen. And, if possible, share any FW file you might have updated with.

[KungFuJosh]

Looking at the code, it's easily visible that the "HW Version" is what I called, in my previous call-graph, the "Model Flag".

So your HW Version is 0xA7 which means it's a:

Ax - TH2830 / ST2830 / SM6023 / DHK6100 / JCX860 / TX6100 / TH7830 / TH2816D / OCT1010 / TH2830HY

That makes sense. And with @Martin72's being A6, it's the same series. It appears that's the thing we need to figure out how to change.

[luudee]

Show me your HW version screen. And, if possible, share any FW file you might have updated with.

Hi TV84,

I think Josh already posted it, but here it is again.

I don't have any firmware, it's on my to-do list to ping the manufacturer ...

Cheers,
luudee

[luudee]

Thanks Josh for pointing out the TRIG setup ...

luudee

[KungFuJosh]

I don't have any firmware, it's on my to-do list to ping the manufacturer ...

Good luck with that. If they actually have something newer than what you have, and miraculously share it, please share it here too. 😉

[KungFuJosh]

Josh, try this one.

Thank you. I tried it, unfortunately it loops between 5 and 10% before failing. That's what usually happens when they fail.

[luudee]

The HW version is hardcoded in the sttwentyeightthirtytwo.sec.hex FW header.

Look at the picture. I don't know what are the consequences.

But if you guys know there is an EEPROM or FRAM inside, as I've previously said, maybe the solution is there and we could try changing there.

I'll try to see if I can get a dump in the next few days.


luudee

[KungFuJosh]

The HW version is hardcoded in the sttwentyeightthirtytwo.sec.hex FW header.

Look at the picture. I don't know what are the consequences.

But if you guys know there is an EEPROM or FRAM inside, as I've previously said, maybe the solution is there and we could try changing there.

There's a C64TA FRAM, I think another chip says 45db321e, I think the 74hct138d is CMOS. I'll pop it back open and get a clearer image of that section.

Can you tell us how to get the info from the chips?

[luudee]

There's a C64TA FRAM, I think another chip says 45db321e, I think the 74hct138d is CMOS. I'll pop it back open and get a clearer image of that section.

Can you tell us how to get the info from the chips?

Hi Josh,

thats not trivial. I just took a quick look at the C64, thats a I2C FRAM, 8KB (which is very small).
I suspect this is being used to save configuration and other data.

The 74hct138 is a CMOS decoder and irrelevant.

I have a J-Link Pro, if it can read the FRAM I will get the contents.

The other FLASH chip someone mentioned is SPI, so that I should be able to read as well.

All I need is time ;-)

Cheers,
luudee

[KungFuJosh]

Here's that section of chips:

[luudee]

Here's that section of chips:

Thank you Josh.


So, the memories are:

1 x B85RC64TA, 8KB, I2C
1 x Atmel/Microchip AT24C512 (64KB EEPROM), I2C
2 x Adesto 45DB321E, 32Mb "Data Flash", SPI


I think I should be able to dump all of them ....

Cheers,
luudee

[zrq]

Maybe someone can try patching out the version checking routine, it's possibly easier than digging into the EEPROM which may need open box and desoldering.

[tv84]

This is the mapping of both files Josh shared (all based in their header - the first 24 bytes):

Code: [Select]

ST2830 FW:
Header: 41424344645E0700A03E1400
Signature: "ABCD"  (MAGIC OK)
Block1 Size:  00075E64   [00000018-00075E7B]
Checksum Blocks1: 3AF4   [00075E7C-0007996F]
Block2 Size:  00143EA0   [00079970-001BD80F]
Checksum Blocks2: A1F5   [001BD810-001C7A04]

ST2832 FW:
Header: 4142434478560700A03E1400
Signature: "ABCD"  (MAGIC OK)
Block1 Size:  00075678   [00000018-0007568F]
Checksum Blocks1: 3AB4   [00075690-00079143]
Block2 Size:  00143EA0   [00079144-001BCFE3]
Checksum Blocks2: A1F5   [001BCFE4-001C71D8]

[zrq]

Yeah. One certainly need to reverse the checksum algo to make the patched firmware file accepted in the upgrade routine. binwalk finds only SHA256 constants in the firmware package, so hopefully no asymmetric crypto.

>>>Oops, I missed that you are already trying that few posts ago.

[KungFuJosh]

This is the mapping of both files Josh shared (all based in their header - the first 24 bytes):

I don't know if it will help or not, but there was a 3rd file earlier as well, for the TH2830 fw.

[tv84]

Now that I know how to calculate the FW Blocks checksums  , tell me for what do we need this. 

As a PoC I've corrected the checksum for the FW I patched a few nights ago so that you can test.

Edit: Added patched FW with correct checksums (I think).

Edit2: For the FW, go here.

[KungFuJosh]

Now that I know how to calculate the FW Blocks checksums  , tell me for what do we need this. 

As a PoC I've corrected the checksum for the FW I patched a few nights ago so that you can test.

Edit: Added patched FW with correct checksums (I think).

You, you're good you!

[KungFuJosh]

I haven't tried the DC bias yet, but check it out... @tv84 wins again! 🏆

[KungFuJosh]

Bias also confirmed! I'm very happy the numeric keypad works for that, otherwise the +/- button moves in mV lol.

[tv84]

You, you're good you!

  Even I am amazed! My first hint was good and the only thing missing was the checksum correction. Nice!

Show us a picture of the "CMOS Setup" upgrade screen where we can see the Hardware Version to see if it still is A07.

[KungFuJosh]

Yup, hw ID is still the same.

Upon startup with the new firmware, my customizations like compensation, and measurement data were all reset. I redid them all, except for some reason short compensation fails. DCR short worked though. 🤷

I might try reflashing again and see if that changes anything. I'll also test some of my reference capacitors to see if the cal changed at all.

Anybody else want to test this fw and see if short compensation works?

Maybe somebody with a "real" 2832 can try the stock version and see if there's an issue with it or not.

Thanks,
Josh