Tiny at85 CHIP INFO NEEDED

We have a ham radio repeater club and 1 of the members is a silent key this past month.
Here is the info we need, We have a repeater when keyed or activated it will give its call sign in morse code. It will stayed keyed until the morse code is finished.
The member who was taking car of this passed away silent key. The interface he used small pc board with the Tiny AT85 chip. We need to get this file for future repeater upgrade.

The members wife got rid of his equipment before we had a chance to where he might of kept the hex file he used to program the AT85 chip.
We have some paper work on what he was doing but no actual file.
Is there a way to read/extract the file from the at85 with blown fuses?

we have blank chips and some info but no file to program the chips

Any help thanks

Look for the C/C++ code, as with luck it was printed out somewhere.

The binary machine code can be extracted from the chip, but you cannot easily convert that into editable source code (at best, it would be obscure AVR assembler code).

Maybe.

It depends on which fuses were programmed when the ATtiny85 was programmed. If the locks bits were programmed that's game over.

If the lock bits were left unprogrammed, it's possible to read the program memory back into a hex file, which you could then use to program more ATtiny85s.

Thanks for the reply.
As i mentioned his wife sold most everything and im sure the info and file was kept on his computer.
The file is a working file so we will not need to edit it just need to have the hex file so we can program for a newer and updated repeater.
I read some place there are places that can read the chip with blown fuses over in China, so there must be some way to get the file of a working chip, I could be wrong in my thinking.

I'm thinking writing some code to send a short morse code message can't be difficult, and I would imagine you guys are well placed to learn to code, even if you can't do it now.

Here is a better explanation. Did not want to complicate things as I was asking somehow to read the chip
The chip is on a pcboard with an sd card reader that has the morse code its not in the chip.
The function of the chip is it will read the busy function of the sd card module then keep the repeater keyed until the identifying call sign is finished then it will unkey the repeater..
So repeater is activated the sd card is activated and the at85 chip will keep the repeater keyed until its over.
We can put anything on the sd card reader and will play.
So we need the at85 program. The pc boards and module are all designed and we have a good supply of them to add to different repeaters.
I guess I will have to look into 1 of those Chinese companies that can extract files from chips. Get a price and see if they can do the AT85 chip.

You probably can extract the hex code from the ATtiny85. It will be similar to this: attiny - Extract .hex from ATtiny45 using Arduino - Arduino Stack Exchange
However, as @PerryBebbington implied, it is probably better to rewrite the application so you have the C++ source code.
Can you make a copy of the documentation that you have including a schematic and post it in this thread ?

I've just read your last post. An ATtiny85 would have difficulties fully supporting an SD card reader (which is notoriously resourse intensive). Is it just starting/stopping the player ?


Here is a schematic of the at85 pc board and the sd card DF reader.

pin 16 on df reader is high and when activated it will go low this in turn will activate pin 1 on the at85 and then out pin 2 of the 85 to the 2n2222A transistor and this will keep the repeater keyed until the audio on either pin 6 or 8 is done then the repeater is unkeyed. This is all we found except some notes that mean nothing of help.

S1 and S2 are momentary switches that we can chose what call sign and what ever we want on the sd card manually. This setup has no auto advance just manual is all we need.
So ptt in pin 2 at85 chip-repeater keyup will activate it then sd card starts -pin 16 goes low and the at85 chip reads this to keep PTT out keyed which will keep the repeater keyed until sound is over. Then repeater is ready for its next person to key in repeater will spitout its call sign and then unkey when over.

Hope I explained what is going on. I will post the circuit board also,


Here is the pc board it works very will with a few wire hook up into the repeater.

We have 5 repeaters and 4 have it set to when you are through talking and unkey the mic the repeater will keyup and call sign will start.

We have one the is when you key up the call sign will start and we want to change the other 4 to when the repeater starts it will sound the call sign. so we need 4 more 85s programmed for the keyup state stay keyed then unkey when people are through talking. Again hope im explaining this ok. Im the next in line to take this job over but we have no program file.

here is the df player module we use

There seem to be several modules available for purchase: search 'auto CW ID keyer' or similar. Good luck with your project.

Dont need the id keyer as what we have been using for the past 2 years works very well
and we have options to add multi ids on the sd card and push of a switch we can use the one chosen. and if we can get the file all we have to do is change the chip on the pc board nothing else.
thanks for your suggestion.

As long as the lock bits weren't programmed, this isn't hard. Even though from the schematic, it looks like the reset pin is being used as I/O, so the stock ArduinoISP sketch won't do the job. You'll have to build yourself a high voltage ATtiny programmer like this:

Program the Nano with the modified HV ArduinoISP sketch from here

And use avrdude to read the flash memory into a hex file. Use the modified ISP sketch to set the fuses in a new 85, then use avrdude to program the hex file into the new 85. Repeat as required.

the fuses are blown as we tried to read the chip no dice.
We have a programmer that we have been using the XGpro TLL86plus and also a pickit 3 programmer works but use the XGpro.
When we read we get all FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.

So what you posted will it read the chip with blown fuse??????????

At least some of the fuses are programmed. The external reset has been disabled so that pin can be used as an input. The clock speed, startup conditions and source have been set. That's not the issue. The issue is whether or not the lock bits have been programmed. As I said, as long as the lock bits aren't programmed you can read the memory. Since reset has been disabled, you'd need a HV programmer such as I showed. I was unaware until your last message that you had a programmer and had already tried to read the chips. Does it have a HV programming mode, or does it expect the reset line to still be enabled?

I will have to check on that and post back.

thanks for the help much appreciated

OK. I see that the ATTiny85 is simply controlling a DF player of this type: DFPlayer Mini Mp3 Player - DFRobot Wiki
It looks like the ATTiny85 may be configured as Digispark because, as has been pointed out, the reset pin has been configured as a GPIO pin. Digispark ATtiny85 Pinout and Configuration - CyberBlogSpot
In principle, it is should not be difficult to recreate a functioning system from the details you have provided.

In the event that the lock bits have been programmed, have you considered just remaking the program?

I'm assuming that when PTT_IN goes low, the DFplayer is instructed to play the same track each time. PTT_OUT and LED1 outputs go high. BUSY is monitored (after an appropriate delay to allow the track to start playing and BUSY to go LOW) until it goes HIGH. When it does, PTT_OUT and LED1 outputs go LOW again.

If S1 or S2 is pressed, the DFplayer starts playing a particular track and BUSY goes LOW. The 85 is monitoring the busy line and as soon as it sees that the DFplayer is playing, it sets PTT_OUT and LED1 outputs HIGh until such time as BUSY goes HIGH (the track's done), at which time it sets PTT_OUT and LED1 outputs LOW again.

Something like this (which compiles but I haven't tried out on hardware yet, so it probably doesn't work due to a lamebrain mistake or three):

#include <SoftwareSerial.h>

const byte dfPlayerTx = 0;
const byte dfPlayerRx = 1;
const byte pttIn = 2;
const byte pttOut = 3;
const byte ledOut = 4;
const byte busyIn = 5;

SoftwareSerial tinySerial(dfPlayerRx,dfPlayerTx);

const char playTrack1[] = {
   '\x7E', '\xFF', '\x06', '\x03', '\x00', '\x00', '\x01', '\xFF', '\xE6', '\xFF'
};

void setup() {
   tinySerial.begin(9600);
   pinMode(pttIn, INPUT);
   digitalWrite(pttOut, LOW);
   pinMode(pttOut, OUTPUT);
   digitalWrite(ledOut, LOW);
   pinMode(ledOut, OUTPUT);
   pinMode(busyIn, INPUT);
}

bool oldPttInState = HIGH;
bool isPlaying = false;

void loop() {
   if( !isPlaying && oldPttInState == HIGH && digitalRead(pttIn) == LOW ) {
      oldPttInState = LOW;
      digitalWrite(pttOut, HIGH);
      digitalWrite(ledOut, HIGH);
      tinySerial.write(playTrack1, sizeof playTrack1);
      isPlaying = true;
      delay(750); // allow time for BUSY to go LOW
   } else if( oldPttInState == LOW && digitalRead(pttIn) == HIGH ) {
      oldPttInState = HIGH;
   }
   if( !isPlaying && digitalRead(busyIn) == LOW ) {
      isPlaying = true;
      digitalWrite(pttOut, HIGH);
      digitalWrite(ledOut, HIGH);
   } else if( isPlaying && digitalRead(busyIn) == HIGH ) {      
      isPlaying = false;
      digitalWrite(pttOut, LOW);
      digitalWrite(ledOut, LOW);
   }
}

When someone keys up on the repeater the sd player starts to play pin 16 goes low and then to the at85 chip. So a PTT in starts this and the PTT out keeps the repeater keyed until the sd sound is done then the repeater is unkeyed until the next person keys it up

Well if someone can write a good working file to work in the already pc board we had made from PCway in China I would be willing to pay for your time for sure would save us a lot of time.
I'm also waiting for a reply from a company in china to see if they can extract the file and how much would it cost.