M-Systems Disk On Chip Problems

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I decided to make use of the DIsk On Chip flash disk units I have on my "stock".

The device is connected to a system like a 8 bit wide memory. The electrical signals are obvious and there was no problem in getting those bit-banged.

After powering up the device acts like a ROM. I can read the contents, the first two bytes being 0x55 and 0xAA (no shorts in data wires :) ).

I have also done comprehensive searc in the net (including this forum) to figure out how this device is steered.

There was a driver with source code for Linux - however - it does not tell how to get this device off the reset mode...

Any documentation to this device would be greatly appreciated - the ones I have found are more like brochures for marketin persons - they do nothing to help in figuring out the functionality of this device.

The device is: MD2202-D192
Originally there were manufactured by M-Systems but that company is long gone - acquired by San...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If this thing is pretending to be a disk you'd expect 0x55/0xAA in bytes 510 and 511 - not in the first two bytes?

(the 0x55/0xAA is the validity marker at the end of the MBR - first 512 byte sector)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about these utils from msys?

Attachment(s): 

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
If this thing is pretending to be a disk you'd expect 0x55/0xAA in bytes 510 and 511 - not in the first two bytes?

(the 0x55/0xAA is the validity marker at the end of the MBR - first 512 byte sector)

Actually the first two bytes are the 0x55/0xAA and there is another at:
01FF 00
0200 55
0201 AA

Which is 512 / 513 :)

Checking the address lines :)

Thanks for the documents and the utility set (for MsDos). I already have all those. For example the document "DiskOnChip 2000 DIP" (Thanks RickB) has all the electrical stuff but none of the logical.

Chapter 4. Operating Modes is a good start but that section is only under 10 lines long and contains no actual data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

WooHooo ! ;)

I figured it out.

This device has a register which is used to controle the entire chip. It is called DOCControl.

Special thanks to Mr. David Woodhouse to figuring out this for me.

The routine was buried in a Linux module called docprobe and it contained the following:

/* Reset the DiskOnChip ASIC */
	WriteDOC(DOC_MODE_CLR_ERR | DOC_MODE_MDWREN | DOC_MODE_RESET,
		 window, DOCControl);
	WriteDOC(DOC_MODE_CLR_ERR | DOC_MODE_MDWREN | DOC_MODE_RESET,
		 window, DOCControl);

	/* Enable the DiskOnChip ASIC */
	WriteDOC(DOC_MODE_CLR_ERR | DOC_MODE_MDWREN | DOC_MODE_NORMAL,
		 window, DOCControl);
	WriteDOC(DOC_MODE_CLR_ERR | DOC_MODE_MDWREN | DOC_MODE_NORMAL,
		 window, DOCControl);

After finding THAT it has been very easy to iron out all my own mistakes and minterpretations of the driver.

Note on the above code that the commands are executed twice. If the command is executed once only nothing will happen. The entire device is fed up with logic like this - for example every time the CDSNControl register is accessed (read or write) it must be followed by 4 reads to the NOP register or else ...(will escort the responsible engineer behind my sauna and teach him facts about simplicity).

I will put this work somewhere in public so that people need not invent this wheel again.

I am NOT using the Flash disk as disk but rather as normal flash memory. The project is a long-goer - the tube tester. The 5 disks will hold the tube measurement instructions, pinning and other stuff like that.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Congratulations on getting it to work! Ain't it sweet? :)

Actually, they have pretty good reasons for requiring those strict schemes - external interference. It is very possible that other nearby devices will produce enough noise to induce glitches in the control lines. If these happen to look like a command, and the chip follows it blindly... well, you may just be locked out of your chip!

Also, it gives a rudimentary protection against sudden power loss. Of course, the power could still be lost after all the hoops have been jumped through and still possibly bricking the chip...

And thirdly, it's a way to debug the engineer, too. If you write drivers for the chip that accidentally write to the wrong memory address once in a while (oh boy, been there, done that), it won't hurt the chip. And it makes reverse-engineering a pain, which might be what they want. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi eskoilola,

Have You made the Code public somewhere ?

Best Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Afaik eskiola hasn't been here for quite some time

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

...but Britney seems to have made a comeback though....

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay,

There exist a document called "Software Requirement" for the Disk On Chip device.

Maybe someone have this docment ?

Best Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All the disk on chip utils are in that zip file about 5 messages up?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The zip file only contains ms-dos utilities. I need the low level documentation so I can use it in a AVR project.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A sdcard would be somuch simpler methinks. The linux drivers should give some clues if you want to persist.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Disk on Chip can be attached to the external memory bus like a eeprom with a 2K memory window with random access. After some consideration this is the best solution for my project compared to a solution with a sdram where I have to read the data from the sdram into a 2K buffer, memory which I currently almost do not have. Of cause I could just increase the hardware complexity and add an external sram for the buffer.
But on the other hand I will not use the Disk on Chip solution without a proper documentation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you aware that the disk on chip devices were discontinued many years ago?

Also don't confuse sdram with sdcard - they are totally different devices.

As for lack of ram, choose a device with enough ram!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's a project I have to continue from a previous colleague who started it. We have 1000pcs of the Disk on Chip on stock, which someone ordered a little bit to early.... they were so cheap so we just had to buy them....

Yes, I mean sdcard and not sdram.

I would like to thank everybody for the inputs and I will put the Disk on Chip solution down the drain together with the source code and the 1000pcs of Disk on Chip devices.