Pico TC-08 Thermocouple Data Logger EEPROM

[ZTE]

Hi all,

I have a Pico TC-08 that has corrupted its internal EEPROM a 24C02WP. I was hoping somebody might have a TC-08 that they could dump the EEPROM contents from.

Thanks

[voltsandjolts]

Which TC-08 do you have, the RS232 or the USB version?

[ZTE]

USB version

[voltsandjolts]

When you connect the usb, what does it show as in Device Manager? (assuming your on Windows)

[voltsandjolts]

The Picolog 1012 and 1216 are based on an STM32F103 but (IIRC) the TC-08 USB is based on a Cypress Ez-USB device. It has an eeprom which simply holds the VID:PID for initial enumeration, thereafter the Picolog software downloads the required firmware (8051 arch) to the device. The device then re-enumerates and is ready for use. So, I believe the info you need is just a few bytes of VID:PID and such for the eeprom attached to the Cypress chip.

You can use fx2tool described at the link below to read and write the eeprom.
Someone with access to a TC-08 USB could use it to read the info you need without having to open their device.

https://www.eevblog.com/forum/testgear/saleae-clone-24mhz-8-channel-la-looses-its-brains/msg4050142/#msg4050142

edit:
Ahh, there maybe be calibration info in that eeprom also, for adc channel offsets IIRC...or the calibration is stored elsewhere.

[ZTE]

Thank you, the fault started out as the device showing up as having a PID of FF FF so I corrected that in the PROM so it now shows as 1000 and installs the drivers okay. But when I try to access it via picolog I hear it disconnect then reconnect and the LED turns green on the TC-08 so I assume its enumerating okay!

But thats where PicoLog hangs. I then tried to access it with a python library as I noticed in the programmer literature there was some more detailed driver errors available. The Python library returned the driver error USBTC08_ERROR_CONFIG_FAIL, Missing or corrupted EEPROM.
https://www.picotech.com/download/manuals/usb-tc08-thermocouple-data-logger-programmers-guide.pdf Page 28

So I think you are correct that there might be some calibration values missing, also at the end of the PROM are some bytes 0E 04. I did wonder if these might be a CRC of some sort.

Thank you so much for the help and advice so far!

[voltsandjolts]

That's good, sounds like you are making progress. Now to fix the corrupt calibration....

Those bytes you mention could well be the checksum bytes.
I'm not sure what method they are using but it is weak because you can change the data to some extent and the checksum still works, e.g. subtract 0x01 from a byte and add it elsewhere.
There is a hint on sigrok wiki https://sigrok.org/wiki/Pico_Technology_PicoScope_3206:

There is a checksum, but is very weak and overly complicated. The last two bytes contain the number of iterations that have to be done to a 14 bit LFSR to get a value that equals the sum of the preceding data when interpreted as signed bytes. The weakness comes from their method of reducing the sum to 14 bits: During summing they reset the intermediate value to zero as soon as it uses more than 14 bits. As the bytes added are signed, this happens very often.

If anyone figures out the checksum algorithm, please let us know!


Anyway, here is the cal data from a TC-08 USB.
You can maybe work out where in memory it goes by the location of those checksum bytes.
The zeroes were formally channel offsets for that particular unit, (32bit vars IIRC) subtracted from the raw ADC values but I set them to zero for my particular requirements. You might be able to do a new cal by shorting out all the channel inputs, reading the data and changing the offsets, if you really need to.

Code: [Select]

const uint8_t cmd_get_cal_response[256] = {

    0xc0, 0xe9, 0x0c, 0x00, 0x10, 0x01, 0x00, 0x00, 0x01, 0x01, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, /* ................ */
    0x00, 0x00, 0x00, 0x41, 0x4f, 0x31, 0x30, 0x35, 0x2f, 0x37, 0x30, 0x35, 0x00, 0x31, 0x37, 0x44, /* ...AO105/705.17D */
    0x65, 0x63, 0x31, 0x34, 0x00, 0x00, 0x08, 0xe3, 0x00, 0x00, 0xfe, 0x34, 0x00, 0x00, 0x02, 0x7f, /* ec14.......4.... */
    0x00, 0x00, 0xfd, 0x99, 0xad, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* ................ */
  
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xcb, 0x0a,
    
  /* note checksum in last two bytes is over the preceding 254 bytes */
  /* you can move bytes around (to some extent) and checksum still works OK */
    
};

[voltsandjolts]

Doh, silly me, it's obvious where the above data goes, since it's 256 bytes going into a 256 byte eeprom!
(I grabbed it using wireshark couple of years ago..don't have access to TC-08 now)

The data I posted above starts with the VID:PID 0x0ce9:0x1000 in the format expected by the cypress ez-usb device.

Code: [Select]

0xc0, 0xe9, 0x0c, 0x00, 0x10,

Yeh, so just write that 256 bytes to your eeprom using fx2tool and it should work.

[mikerj]

This seems like a very bizarre scheme with no obvious advantages over a 16 bit CRC, in fact little advantage over a simple 16 bit sum or XOR type checksum.

Did you reverse engineer the checksum method?  Just wondering how that was done to determine that it used a LFSR and how it was used, but the LFSR taps and initial values are unknown.  If correct this should be quite easy to brute force if a some good EEPROM dumps can be found. 

Also your comment "note checksum in last two bytes is over whole 256 bytes" is maybe missing some information.  Do you really mean the initial 14 bit signed sum is performed over bytes 0-255 rather than 0-253?  If so there seems to be a chicken and egg situation, as the value in bytes 254/255 would be changed after the required number of LFSR iterations is calculated, which would then change the 14 bit sum value...

[voltsandjolts]

That checksum info was from the sigrok wiki, not sure who discovered that...maybe someone with a Hex-Rays IDA install

[mikerj]

That checksum info was from the sigrok wiki, not sure who discovered that...maybe someone with a Hex-Rays IDA install

Thanks, I wasn't sure if you had maybe contributed to the wiki.  I was editing my post as you replied as I hoped if you could clarify the comment in your code regarding the number of bytes used in the sum?

[voltsandjolts]

Ah yes, 254 bytes. Fixed in code comment.

[ZTE]

I couldn't get the fx2tool working (got the error "read of closed file") but I removed the EEPROM and wrote it using the data you supplied and it works perfectly! Thank you!

Do you have any info about the calibration offsets? Are these written via the GUI or written to the PROM in the factory?

Also would you happen to have a dump for a PicoScope 2204A, I attempted to dump the EEPROM from mine, got the holder backwards and fried the IC. Goodnight 2204A.

 

[voltsandjolts]

TC-08 fixed

Calibration offsets are written at factory AFAIK. You should be able to work out the positions easily enough, I remember it was first coeff was for first channel and so on.

Can't help with the 2204A. If it's cypress ez-usb based like the TC-08 then someone could use fx2tool to read eeprom without opening. Or use wireshark to grab the data during enumeration cycle.

Edit: IIRC there aren't any gain calibration coefficients, just channel offsets.

[ZTE]

Any ideas on why my fx2tool won't behave? I'll have a play with the calibration. I've bought another 2204A so I'll dump that and provide the dump here.

[voltsandjolts]

Any ideas on why my fx2tool won't behave?

Based on the near zero information you have provided, I don't know!

The fx2tool documentation is here and the code is here.

Does this show help info?

Code: [Select]

py -m fx2.fx2tool --help

In Windows you need to use zadig to apply the WINusb driver to your usb device, although the Pico TC-08 driver might just be a WinUSB wrapper and it's already using it. I don't remember.

Also need libusb installed; copy prebuilt libusb-1.0.dll from here (downloads>latest win binaries) to somewhere on your system path. In the 7z archive you probably need the "\libusb-1.0.26-binaries\VS2015-x64\dll\libusb-1.0.dll".

Can you read back the eeprom?

Code: [Select]

py -m fx2.fx2tool -B -d 0ce9:1000 read_eeprom -W 1 0 256

[ZTE]

Hi all,

So I had a real mare with fx2tool, on both Linux and on Windows.

I eventually installed it on windows but from the github source not via pip, as the pip binary was outdated and a bug was causing the "read of closed file" error.

Once I started to install it from source I encountered another issue when running the command "python software/setup.py develop --user". It returned "error: Multiple top-level packages discovered in a flat-layout: ['firmware', 'software']." To get round this I CD'd into the software dir and ran "python setup.py develop --user"

If you still have issues you might need to try adding:

Code: [Select]

[tool.setuptools]
py-modules = []

To the end of pyproject.toml

I never did get it to compile and install properly under linux, when running the develop command I kept getting unknown egg returned. I think this was down to two version of setuptools on Debian fighting, but I couldnt fix it.

Once installed I used the following command to dump the EEPROM to a bin file.
fx2tool.exe -B -d 0ce9:1007 -F bin read_eeprom -W 1 0 256 > test.bin

And to write it back I used
fx2tool.exe -B -d 04B4:8613 write_eeprom -W 1 -a 0 -f test.bin
Note the diferent VID and PID because this was a completely blank EEPROM fitted to the device so the cyprus controller presented with a default VID&PID. I also had to use ZADIAG to install the winusb driver for this unknown device before I could use fx2tool.

[voltsandjolts]

I couldn't get the fx2tool working (got the error "read of closed file")

I eventually installed it on windows but from the github source not via pip, as the pip binary was outdated and a bug was causing the "read of closed file" error.

Aggghhh, I just hit that error too. The fx2 package in pip is lacking months old fixes:
https://github.com/whitequark/libfx2/commit/82d154153f548b29b1be60f1c11d7a5bc102486d

Without this fix, 'fx2load --bootloader' will die with the error message "read of closed file".

You can manually fix that, line 352 in fx2tool.py.
On Windows, pip keeps the fx2 package here:
C:\Users\<username>\AppData\Local\Programs\Python\Python311\Lib\site-packages\fx2

Edit: pip package now updated, so you should get the latest version

Code: [Select]

pip install fx2 --upgrade