EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: Ardov on March 08, 2018, 05:35:09 pm
-
First of all, greetings to all the community here. It is my first post and i am very excited to join this very fine and superb forum!
I am going to need your help for a repair that i want to do which involves NOR Flash programming using a TL866II Plus programmer.
INTRODUCTION
I have a Yamaha DVD-S1700 DVD/SACD player.
You may wonder why i am trying to revive this device. Who uses DVD players anyway? Well this one is a special device that i use as a DVD-Audio and SACD player. It contains some audiophile grade audio
circuitry inside such as Burr Brown DACs and direct DSD to analog all the way to the output without lossy conversion to PCM. Anyway, let's get to the technical stuff!
THE PROBLEM
Unfortunately after a failed firmware update, the device seems to be bricked. To be honest, i did a very stupid thing and didn't wait for the flash proceedure to complete and i turned it off right in the middle of the proceedure.
The device powers on but no information shows up on the VFD (front display) and no signal comes out, no video and of course no audio. No response from the keys on the remote, and no response from the keys on front of the device. DVD/CD mechanism appears dead too, no eject function works.
BUT, using the remote, the DVD Player turns on and off normally and i can confirm this because the Optical TOSLINK connector on the back lights up and then goes off when i give the power off command from the front button or from the remote control.
THE IDEA
Locate the chip that the firmware (although corrupt now) is stored in, desolder it, put it in the programmer, erase it by filling it with FF values and then burn the firmware.
I already have the original firmware in an IMG file.
PRELIMINARY RESEARCH
This player has a similar design as both my Samsung HD745 and Samsung HD945 DVD/SACD players. They are all based on a Vaddis 778 chip.
By reading the service manual of the Yamaha DVD-S1700, available to the public here: (and comparing it to the Samsungs' service manuals)
https://www.manualslib.com/manual/767489/Yamaha-Dvd-S1700.html (https://www.manualslib.com/manual/767489/Yamaha-Dvd-S1700.html)
i found out that the platform is fairly simple. The Vaddis 778 single chip plays the role of God in these devices. It controls the dvd mechanism, motor, optical pickup unit, and VERY IMPORTANT of course provides the on-screen display, menus, and also Decodes Video and Audio and passes the analog or digital signal to the other IC on the main PCB, the HDMI encoder and transmitter and a Faroudja DCDi DSP chip for upscaling and deinterlacing.
This chip is connected to an MCU from ST Microelectronics, to be precise it's the ST72F321R 8-bit microprocessor.
Now, this chip provides the ON-OFF functions, lights up some LEDs on the front panel and of course controls the VFD (front display). Last thing it does is that it controls the IR sensor that receives the commands from the remote control unit.
TARGETED RESEARCH
A quick look at the mainboard PCB reveals that the Vaddis 778 chip is connected to a NOR Parallel Flash device, the ST M29W160ET (70N6) in TSOP-48 packaging which has a capacity of 16Mbit (2M X 8 or 1M X 16).
Also it's connected to a 24C16 Serial EEPROM which has an I2C interface.
The last one is an 16K EEPROM and in no way can the firmware be stored there since the firmware file is exactly 0x1FF001 bytes. I assume the 24C16 is being used by the Vaddis as a ROM that contains the boot and initialization code and maybe the Region Lock of the DVD player (Region 0-6) .
By analyzing the firmware file it seems it is not encrypted. Using an ordinary HEX editor one can literally read Menu Items in all supported languages in the firmware. Also, all indications that are meant to be displayed on the front panel display are there in plain text. On-Screen Display messages are there in many languages and some verbose parts of the code.
Now, the M29W160ET device has a Top Boot configuration and the blocks are organized asymmetrically.
From the datasheet:
in x8 mode:
Blocks [30:0] are all 64KB ones
Block 31 is 32KB and can be used as application specific area
Blocks [33:32] are 8KB areas for parameter storage
Block 34 is a 16KB area which contains the Boot code to initialize a microprocessor
The firmware image file seems that it doesn't make full use of those "special" blocks that this specific NOR Flash supports. Also it doesn't "use" the boot area (001F C000 - 001F FFFF) but has only one byte in this range, altered with the value F9 in hex at memory position 1FF000 which marks the end of the image file, it's the last byte. The rest are FF values which means empty.
I am very troubled about how the firmware should be written in the M29W10ET.
The normal proceedure requires a CD-R to be written in ISO9660 filesystem format which contains two files, an UPDATE.VER 9 bytes file which is a plain text file in ANSI encoding which contains only a string that is actually the firmware image filename with its extension, to be precise it's BUILD.IMG . The Vaddis chip recognises this simple layout, prepares the NOR Flash in programming mode and programms it.
I was worried that the Vaddis chip:
A) may do some block comparison and preserve some already "factory programmed blocks" while erasing and writing the others.
B) may use offset values to write data down using internal logic.
The Zoran company has gone defunct since 2011 and there is no documentation as to how this chip works nor do the datasheets contain useful information.
Going into further investigation i found out that the firmware image file, although doesn't make full use of the NOR Flash's special block structure, it uses Block 31 as an application specific block which contains code about SACD playback and especially TOC Reading. Large address ranges before and after are full of FF values.
Which makes me believe that the firmware file is actually an 1:1 image map of the values to the specific memory addresses to be written without an offset or other tricks under the hood of the Vaddis 778 chip. In simple words, it reads the file and it acts as a blind programming interface without checking or validating anything.
WHAT TO DO?
The idea is to buy a new TL866II Plus USB programmer together with a TSOP-48 adapter and use the new Xgpro TL866II Plus software to burn the image to the M29W160ET after erasing it or even buy some empty M29W160ET chips to experiment with and write directly in those while preserving the corrupt firmware on the original desoldered flash chip.
Question is, is all the above research based on a solid ground?
I believe the Vaddis 778 initializes itself using code written in the small 24C16 Serial EEPROM 16K chip and then reads the firmware file from the NOR flash for internal logic use, menus and messages, and passes data from it to the microprocessor when needed, with which the Vaddis communicates to get keypresses and commands from the remote control in an input-output manner via an I2C bus implementation.
But coming to the real point, how does the Vaddis 778 writes and reads data in the firmware? Is it little endian or big endian 16-bit? Is it simple plain 8-bit?
The difference is big! It's a completely different interpretation of the firmware!
How should i write the NOR Flash with the firmware image file? In 8-bit mode? Or in 16-bit mode? And if it will be done in 16-bit mode should i swap bytes or should i leave it as is?
Also, can someone please describe how memory is written in 8-bit and how in 16-bit mode? I haven't understood the difference between those modes.
Also i remember about a bug on the older TL886 software, the MiniPro, which displayed input binary data in 16-bit as correctly swapped although in reality this wasn't happening so you had to manually swap bytes to really change the endianness.
I am baffled and i don't really know how i should proceed. Any insight on this would be greatly appreciated, really!!!
Thank you all readers and contributors in advance!
P.S.: Binary image file is here if someone wants to have a look!
https://ufile.io/m5s4w (https://ufile.io/m5s4w)
-
Unfortunately after a failed firmware update, the device seems to be bricked. To be honest, i did a very stupid thing and didn't wait for the flash proceedure to complete and i turned it off right in the middle of the proceedure.
All will become clear if you read the contents of the partial update from the flash.
-
I confirm that your bin file is a raw flash image (disassembly shows correct references across entire file, so no inserted headers/checksums there). Do as amyk says - read the flash, check the byte order of read data, write the new data with the same byte order.
-
I would like to thank you guys for your time and your advice! It took me months to get the FlashCAT USB Programmer and the correct ST M29W160ET chips. 2 of my orders from eBay were useless because the chips were factory locked. Although FlashCAT USB developers implemented the special command sequence to program the chip in bypass mode, the DVD player couldn't save preferences set in the menu. So i had to find the correct chip and this took soooo long. The original one, removed from the PCB was destroyed (write and read errors all the time) due to hot air removal station.
But in the end, i finally managed to solder the new chip after programming it with the raw binary file. So my DVD player is revived and works like a charm.
Thank you all!