Eos 400d ( Rebel XTI )

yonomolo

3

Re: Eos 400d ( Rebel XTI )

« Reply #1740 on: 02 / May / 2013, 10:52:16 »

Advertisements

I've installed 400plus for the first time yesterday. I was especially interested in the AEB script, so that's the only thing I pretty much tried. It worked great yesterday, but without doing anything else, today it started behaving in a weird way. It doesn't matter how many frames I set to take (4, 6, 9, etc...), it just keep taking pictures forever (well, I don't now when it would stop, but I just turned off the camera at 27). I've tried different combinations in the settings, and even reformating the card, but it's still happening. Any ideas?

Thanks a lot in advance, and thanks a lot for creating this. It definitely gives my camera a new life.

EDIT: I have steps that can be reproduced now, so I'll submit an issue in the 400plus project page. Following some steps (cleaning settings, formating card, etc...) seems to get it fixed, but it only works the first time, then it starts having the same problem again.

« Last Edit: 02 / May / 2013, 11:30:04 by yonomolo »

Logged

eduperez

426

Re: Eos 400d ( Rebel XTI )

« Reply #1741 on: 02 / May / 2013, 11:45:12 »

This is indeed a bug: camera shout not let you set an even number of shots; and when you set an even number of shots, the script fails and shots endlessly. Will be fixed as soon as possible, thanks for reporting.

Logged

yonomolo

3

Re: Eos 400d ( Rebel XTI )

« Reply #1742 on: 02 / May / 2013, 11:53:42 »

Yeah, that's a question I was about to ask. Why do the settings show 4 and 6 instead of 5 and 7. And after you mentioned, I've just did another test and it wasn't that the first time worked, but not anytime after that. It was just that it turned out, as a coincidence, that every first time I tried I was trying with an odd number (3 or 9).
It actually works fine all the time with an odd number, so basically the problem is what you said, it's allowing me to set even numbers and it freaks out.

Thanks a lot for addressing this!

Logged

eduperez

426

Re: Eos 400d ( Rebel XTI )

« Reply #1743 on: 02 / May / 2013, 16:42:32 »

Quote from: yonomolo on 02 / May / 2013, 11:53:42

Yeah, that's a question I was about to ask. Why do the settings show 4 and 6 instead of 5 and 7. And after you mentioned, I've just did another test and it wasn't that the first time worked, but not anytime after that. It was just that it turned out, as a coincidence, that every first time I tried I was trying with an odd number (3 or 9).
It actually works fine all the time with an odd number, so basically the problem is what you said, it's allowing me to set even numbers and it freaks out.

Thanks a lot for addressing this!

Fixed in the 20130414-01 release; thanks for reporting!

Logged

yonomolo

3

Re: Eos 400d ( Rebel XTI )

« Reply #1744 on: 02 / May / 2013, 17:16:53 »

Quote from: eduperez on 02 / May / 2013, 16:42:32

Fixed in the 20130414-01 release; thanks for reporting!

Awesome! Thanks a lot!

By the way, is it possible for end users to create scripts, like in CHDK? I don't know if the same applies or it works differently. If it is, is Lua supported?

Thanks again!

Logged

eduperez

426

Re: Eos 400d ( Rebel XTI )

« Reply #1745 on: 02 / May / 2013, 17:19:05 »

Quote from: yonomolo on 02 / May / 2013, 17:16:53

Quote from: eduperez on 02 / May / 2013, 16:42:32
Fixed in the 20130414-01 release; thanks for reporting!

Awesome! Thanks a lot!

By the way, is it possible for end users to create scripts, like in CHDK? I don't know if the same applies or it works differently. If it is, is Lua supported?

Thanks again!

No, I'm afraid there is no support for LUA or any other scripting language.

Logged

0xAF

220

Re: Eos 400d ( Rebel XTI )

« Reply #1746 on: 02 / May / 2013, 21:03:10 »

@Sergei:

few things:

1. i have "sort of" solution for the entry point.
the linker script needs to be changed.
the entry.o is removed and init.o is placed instead.
then in yout init.c put few asm instructions in the beginning of the file.
see here:
https://code.google.com/p/400plus/source/browse/trunk/init.c
https://code.google.com/p/400plus/source/browse/trunk/link.script
basically, i've moved the entry.S stuff in the C file.
Not the best solution, but still better than separate entry.S or entry.c file.

2. i've ported the cache hacks to 400Plus (used your port actually).
i've added few routines to our cache_hacks.h and few #defines
here it is: https://code.google.com/p/400plus/source/browse/trunk/cache_hacks.h

3. i had problems with cache_lock() the camera was freezing on it (very strange)
i narrowed down the problem ti the D cache lines clearing in dcache_lock().
i've commented out the cache clearing and placed one new routine in it's place (took it from ML)
see here: https://code.google.com/p/400plus/source/browse/trunk/cache_hacks.h#474
then i realized that i do not need dcache_lock() actually and replaced the cache_lock() in init.c with icache_lock() only.
still i dont know why it was freezing on d cache clearing.

4. i found most places in the OFW where the cache is cleared
see here: https://code.google.com/p/400plus/source/browse/trunk/init.c#103
i've NOP'ed 4 instructions only, and put back the function which you were skipping, it's working for me.
you can take this instructions instead of the function which you removed, since they may be called in other places.

5. i did not saw where you patch the CreateMainHeap, so i've patched it
see here: https://code.google.com/p/400plus/source/browse/trunk/init.c#80
you can take this line which will preserve last 128kb of the main heap for our hack.
i know you are using 64kb, but it wont hurt to preserve 128kb.
you do not need to change any memory addresses, you can use this line directly, or you can generate the instruction binary code for 64kb.

there were other stuff, but cant remember now...

« Last Edit: 02 / May / 2013, 21:06:47 by 0xAF »

Logged

// AF

Sergei

114

Re: Eos 400d ( Rebel XTI )

« Reply #1747 on: 03 / May / 2013, 04:43:31 »

Thanks for the information, 0xAF.
I remember when I was changing entry.c or entry.s my camera was freezing on FirmwareEntry(); without any logical reason, so I had to use asm __volatile__ ( "ldr pc, = 0xFF810000\n"); Try to put entry.s back and see if it will fix dcache_lock().

I understand why you changed 0x800000 to 0x7E0000. My question is how does it work without it?

Here is some info about "vmBaseGlobalMapInit" which I disabled to save cache-hacks:
http://www.vxdev.com/docs/vx55man/vxworks/ref/vmBaseLib.html

0xAF, can 400plus catch "trash_button_released" or "jump_button_released" events? If not, check SetSendButtonProc(&My_SendButtonToMC, 0); in my code. Could be useful for something.

I started to work on IR remote code. Right now I can make camera respond to any remote on any key but can't make it respond only on specific keys. Looks like firmware only checking for pulse width and time between pulses.
Code is in remote.h:
http://hostr.co/0MiULSEGLdt3

Logged

0xAF

220

Re: Eos 400d ( Rebel XTI )

« Reply #1748 on: 03 / May / 2013, 07:30:06 »

Quote from: Sergei on 03 / May / 2013, 04:43:31

I understand why you changed 0x800000 to 0x7E0000. My question is how does it work without it?

It will work, but if the camera eats all the memory, the hack is gone...
I'm not sure if our camera can eat all it's memory, but on some (most) cameras with ML it happens.

Quote from: Sergei on 03 / May / 2013, 04:43:31

Here is some info about "vmBaseGlobalMapInit" which I disabled to save cache-hacks:
http://www.vxdev.com/docs/vx55man/vxworks/ref/vmBaseLib.html

I did not know the purpose of this function, Thanks for the link.
Actually you can see my comments in our init.c where I've put the function back and NOP'ed another address.
This address was a call to cacheLib from this function and now when I've read the link, it makes sense.

Quote from: Sergei on 03 / May / 2013, 04:43:31

0xAF, can 400plus catch "trash_button_released" or "jump_button_released" events? If not, check cSetSendButtonProc(&My_SendButtonToMC, 0); in my code. Could be useful for something.

Yeah, I saw the code yesterday, looks interesting.
We have JUMP and TRASH via MainCtrl, I disassembled the MainCtrl routine to get them.
Now with the cache-hacks, I was thinking to remove all this code.
Your code looks better, though.
SetSendButtonProc() this is the function, that could saved me a lot of reverse engineering time when I worked on MainCtrl.

Thanks.

Quote from: Sergei on 03 / May / 2013, 04:43:31

I started to work on IR remote code. Right now I can make camera respond to any remote on any key but can't make it respond only on specific keys. Looks like firmware only checking for pulse width and time between pulses.
Code is in remote.h:
http://hostr.co/0MiULSEGLdt3

Yeah, this is cool.
I know about this settings in the firmware and I had the same idea back in the time, though I never started to play with them. I will check you work and may play with it a bit.

EDIT:
I see you have IR_Log() function, can you log all signals with it ?
I mean when you press some button on a remote, can you distinguish between different remotes/buttons ?
If so, this is great. If not, the enabling of all IR signals is still a good feature.

EDIT2:
BTW, do you know what this MachineCell is and what is it's purpose ?
It looks like it is for some Factory Tests ?

EDIT3:
I took the vram_copy() routine from your code, to invert the OLC colors.
It seems to work, but not when you start the camera for the first time, it draws white first, then after i force any gui update it draws black.
I guess this is because we cannot detect (GUIMode == OLC_MODE) in the first moments. I will try to find a solution.
EDIT3.1:
I've found it...
It was because at the start the camera is changing the mode for a while, to draw the animation for sensor cleaning... so the check should be:
if (FLAG_GUI_MODE == GUIMODE_OLC || FLAG_GUI_MODE == GUIMODE_ACTIVESWEEP_OLC) {...}

« Last Edit: 03 / May / 2013, 10:07:19 by 0xAF »

Logged

// AF

Sergei

114

Re: Eos 400d ( Rebel XTI )

« Reply #1749 on: 03 / May / 2013, 15:24:18 »

Quote from: 0xAF on 03 / May / 2013, 07:30:06

I see you have IR_Log() function, can you log all signals with it ?
I mean when you press some button on a remote, can you distinguish between different remotes/buttons ?
If so, this is great. If not, the enabling of all IR signals is still a good feature.

It will only show error message and width of first and second pulses and, i guess, time between pulses. Camera does very simple check on IR signals. It doesn't decode RC-5 signal so all keys from same remote looks same to camera.

Quote from: 0xAF on 03 / May / 2013, 07:30:06

BTW, do you know what this MachineCell is and what is it's purpose ?
It looks like it is for some Factory Tests ?

No I don't. Maybe it is for factory mode GUI?

Quote from: 0xAF on 03 / May / 2013, 07:30:06

I took the vram_copy() routine from your code, to invert the OLC colors.
It seems to work, but not when you start the camera for the first time, it draws white first, then after i force any gui update it draws black.
I guess this is because we cannot detect (GUIMode == OLC_MODE) in the first moments. I will try to find a solution.
EDIT3.1:
I've found it...
It was because at the start the camera is changing the mode for a while, to draw the animation for sensor cleaning... so the check should be:
if (FLAG_GUI_MODE == GUIMODE_OLC || FLAG_GUI_MODE == GUIMODE_ACTIVESWEEP_OLC) {...}

Thank you very much for the solution! I thought it will be harder to fix it.
I see it still has small part on the screen left which didn't invert. It goes through memcpy in 0xFF92C5FC location. I was trying to fix it with "cache_fake(0xFF92C5FC, BL_INSTR(0xFF92C5FC, &vram_copy), TYPE_ICACHE);"
It invert all screen now but camera freezes right before firmware updates available picture count.

Logged