Creative Zen Vision:M

[Aurix Lexico]

Have you tried writing to the PIC over i2c? Instead of figuring out what the OF does to the PIC, can you try sending something (a single zero perhaps?) to the PIC in hopes of reseting the numbers it returns for a button press? I would try it myself, but I won't be able to install rockbox on my zen till after christmas, when I will buy a CF card and adapter.

[mcuelenaere]

Have you tried writing to the PIC over i2c? Instead of figuring out what the OF does to the PIC, can you try sending something (a single zero perhaps?) to the PIC in hopes of reseting the numbers it returns for a button press? I would try it myself, but I won't be able to install rockbox on my zen till after christmas, when I will buy a CF card and adapter.

I *think* I tried writing stuff to it, but never got anything really useful out it.

BTW, you can try the Rockbox bootloader without breaking anything on your device (the bootloader has capabilities of booting the OF, and as the bootloader is 'our' code you can use it to write to the PIC).

If you need any help in this, ask me

[Aurix Lexico]

The rockbox bootloader is now on my zen. Before I start editing the bootloader, is there a way to recover from me messing up the bootloader? And can you point to a source file that is a good example for reading/writing with I2C.

[mcuelenaere]

The rockbox bootloader is now on my zen. Before I start editing the bootloader, is there a way to recover from me messing up the bootloader?

Yes, just boot into the recovery mode and replace the firmware with either the Rockbox bootloader again or the OF.

And can you point to a source file that is a good example for reading/writing with I2C.

pic-creativezvm.c contains the code which communicates with the PIC.

Using i2c_read(0x07, unsigned char* data, int length) and i2c_write(0x07, unsigned char* data, int length) you can communicate with it directly.

GIO0 is triggered by the PIC when it's about to send a message, so GIO0() is the message handler (in pic-creativezvm.c).

You probably want to enable BUTTON_DEBUG so you can see what messages the PIC sends to the ZVM.

I think send_command_to_pic() is meant to mimic the OF for sending a message to the PIC, so you could try using that.

[imfloflo]

So we can change the bootloader without opening tje device ?

And change the firmware to the alternative rockbox?

[fejfighter]

no, not yet.
only the boot loader can be changed right now. which then loads the creative firmware

@mcuelenaere
other ideas to get around the cfs problem i had thought of:
instead of finding a method to read it
-getting the usb driver to work then format the drive on a computer
-or write a formatter system into a bootloader for installation purposes.
i think i will lean to try and get the the first one done, if a method of communicating is found.
every attempt i had last night i couldnt get a consistant response from components, at one stage i had scroll up recognised as the hold switch...

keep up the good work,
hopefully i can find something of use!

[mcuelenaere]

no, not yet.
only the boot loader can be changed right now. which then loads the creative firmware

@mcuelenaere
other ideas to get around the cfs problem i had thought of:
instead of finding a method to read it
-getting the usb driver to work then format the drive on a computer

I tried that approach for quite some time, but got stuck. I think the USB driver gets as far as sending some control messages on endpoint 0 and that's it (see this site for more info about USB)

-or write a formatter system into a bootloader for installation purposes.

What's the point about having a FAT filesystem if you don't have USB working to put files on it (either through Rockbox or through the OF)?

The OF will get erased by this, and even if you would put the FAT partition at some unused space inside the CFS partition; the OF still wouldn't 1) expose it over MTP because 2) it can't read it and doesn't know about its existence.

i think i will lean to try and get the the first one done, if a method of communicating is found.
every attempt i had last night i couldnt get a consistant response from components, at one stage i had scroll up recognised as the hold switch...

keep up the good work,
hopefully i can find something of use!

You can find the driver here and the datasheet here (ISP1583).

[fejfighter]

no, not yet.
only the boot loader can be changed right now. which then loads the creative firmware

@mcuelenaere
other ideas to get around the cfs problem i had thought of:
instead of finding a method to read it
-getting the usb driver to work then format the drive on a computer

I tried that approach for quite some time, but got stuck. I think the USB driver gets as far as sending some control messages on endpoint 0 and that's it (see this site for more info about USB)

-or write a formatter system into a bootloader for installation purposes.

What's the point about having FAT filesystem if you don't have USB working to put files on it (either through Rockbox or through the OF)?

The OF will get erased by this, and even if you would put the FAT partition at some unused space inside the CFS partition; the OF still wouldn't 1) expose it over MTP because 2) it can't read it and doesn't know about its existence.

i completely over looked that..
i never considered the file transfer that will be required

You can find the driver here and the datasheet here (ISP1583).

i think i have been looking at the wrong files and datasheets, using the pic instead, i will try the other approach now

[mcuelenaere]

I think currently the main thing we should focus on is the CFS file system, as we almost have all pieces of the puzzle, but we just need to fit them correctly.

And whenever we have access to the VFSYS file, we can put a FAT partition on it and use it to boot Rockbox (+ we have the advantage of accessing it over USB through the OF using the Removable Disk Drive option).

Last time I checked, the code was working reliably (I even think I committed (non-working) code to SVN) but there's a problem with getting the different CFS sectors together and to 'merge' them to the FAT file system (at about p.42-43 at this thread you can read a bit more about it).

[Aurix Lexico]

Using send_command_to_pic, I've tried writing everything between 0x0000 and 0xFFFF to the PIC. I then tried just changing the third byte (aka between 0x00 << 16 and 0xFF << 16) and then tried just changing the fourth byte (aka between 0x00 << 24 and 0xFF << 24). It didn't appear to do anything. The keycodes never changed. Most of the time the function gave me back 0xFF0F0000, but every once in a while (once in every 30ish calls to send_command...), with absolutely no pattern that I can find, it will return a different code. Well, actually, if you move your finger over the touchpad very fast it will start returning 0xFFFFFFFF. All I can think about is, what is the point of the PIC? It has to have a point, it has to serve a purpose otherwise why even bother with it in the first place? Why change the keycodes at random?

[mcuelenaere]

Using send_command_to_pic, I've tried writing everything between 0x0000 and 0xFFFF to the PIC. I then tried just changing the third byte (aka between 0x00 << 16 and 0xFF << 16) and then tried just changing the fourth byte (aka between 0x00 << 24 and 0xFF << 24). It didn't appear to do anything. The keycodes never changed. Most of the time the function gave me back 0xFF0F0000, but every once in a while (once in every 30ish calls to send_command...), with absolutely no pattern that I can find, it will return a different code. Well, actually, if you move your finger over the touchpad very fast it will start returning 0xFFFFFFFF. All I can think about is, what is the point of the PIC? It has to have a point, it has to serve a purpose otherwise why even bother with it in the first place? Why change the keycodes at random?

I know it is used to disable the touchpad.
It is also used to give information about various input (i.e. keys, TV-out, headphones, USB inserted, charger inserted, ...)
But because the protocol is completely proprietary (and custom-designed, like we're used of Creative..), I think the only way to figure out how it works is reverse engineering the OF...

Why change the keycodes at random?
I don't know, perhaps we just don't understand the protocol completely? Perhaps there's something wrong with the I²C implementation? (although I doubt that)

[Aurix Lexico]

Well, is there a way for me to extract and disassemble the OF? I'm not great with assembly, but I still want to try 

[mcuelenaere]

Well, is there a way for me to extract and disassemble the OF? I'm not great with assembly, but I still want to try 

Yes, have you already downloaded ZenUtils?

If so, with it you're able to extract the OF from the Creative firmware updater software and decrypt it.

The next step is disassembling, and if you have access to IDA there are some tools on the wiki which help IDA understand the firmware format.

I think I already helped somebody else explaining how the OF's firmware structure basically works, I'll look for that info and I'll post it here if I find it.

[Aurix Lexico]

I've been looking at the disassembled code for the PIC the last couple of days. The function that handles the i2c communication is conveniently labeled "i2c_handler" and I've been tracing through the 550ish lines of assembler that make it up. Unfortunately, "i2c_handler" is the only actual name in the entire 55k line file, all the other function and variable names are just numbers based on where it is in the file. Even so, the actual code is fairly easy to understand since PIC 18 has very few instructions. I still haven't found anything useful yet, though

[mcuelenaere]

I've been looking at the disassembled code for the PIC the last couple of days. The function that handles the i2c communication is conveniently labeled "i2c_handler" and I've been tracing through the 550ish lines of assembler that make it up. Unfortunately, "i2c_handler" is the only actual name in the entire 55k line file, all the other function and variable names are just numbers based on where it is in the file. Even so, the actual code is fairly easy to understand since PIC 18 has very few instructions. I still haven't found anything useful yet, though

I remember myself RE that same piece of code (lost all the files though...), and I think at the time I got some documentation about how the PIC handles I²C (probably source code or so)..

You have seen the datasheet I suppose?

You could also try looking at the Microchip.com site if they provide code/a framework for handling I²C, if they did Creative probably used it and you can abstract away at least one layer then.