Eos 400d ( Rebel XTI ) - page 177 - DSLR Hack development - CHDK Forum
« previous next »
Pages: 1 ... 172 173 174 175 176 [177] 178 179 180 181 182 ... 188   Go Down

Eos 400d ( Rebel XTI )

  • 1871 Replies
  • 891400 Views
*

Offline JoeNeptune

  • **
  • 92
Re: Eos 400d ( Rebel XTI )
« Reply #1760 on: 08 / June / 2013, 11:20:58 »
Advertisements
Thank you very much for your support.

Maybe the light meter could work as a laser sensor?
Or perhaps it could detect a  lasers interference with something like the auto-focus.
Perhaps this means of high speed triggering, with no external switching, may have advantages over others where it may be just a few cycles of the processor to activate.
But in any case I think it would be a lot of fun and worth while to try it.



Logged
*

Offline Sergei

  • ***
  • 114
Re: Eos 400d ( Rebel XTI )
« Reply #1761 on: 09 / June / 2013, 06:03:23 »
Quote from: JoeNeptune on 08 / June / 2013, 11:20:58
Thank you very much for your support.

Maybe the light meter could work as a laser sensor?
Or perhaps it could detect a  lasers interference with something like the auto-focus.
Perhaps this means of high speed triggering, with no external switching, may have advantages over others where it may be just a few cycles of the processor to activate.
But in any case I think it would be a lot of fun and worth while to try it.
I don't think it's possible to do something like that.
Logged
*

Offline eduperez

  • ****
  • 426
Re: Eos 400d ( Rebel XTI )
« Reply #1762 on: 12 / June / 2013, 03:08:43 »
@Sergei / @0xAF:

I am experiencing random camera lock-ups, that I cannot fix myself, and would like to hear your opinion on this. As far as I know, the symptoms when this happens are:

* Just after a shot has been taken, all buttons stop responding, and the display does not show our overlay.
* Camera can take another photograph, however (but it does not get to the CF card)
* Finally, the display goes off, and the camera is completely locked (it cannot even be turned off).

In 400plus, we always overlay something on the display, so my first suspect was the overlay code; I commented out that part, and it seems to work (but you can never be sure with random bugs). This would confirm that the source of the problem is in the overlay code.

Now, how can it be possible that we always overlay something, but I see nothing in the display? So, my next suspect is the pointer to the display that we receive: if we received a wrong pointer, we would be writing somewhere else in the memory, and that could explain the lock-up.

I tried to log the value that we receive in that parameter, and it seems to be constant (I could not reproduce the issue and see what value we received when it happens, however); there is also that weird constant value that we add to the pointer.

And this is all I know about this issue... I have been banging my head against the code for weeks, but I cannot find anything else.  Do you have any ideas, please?

Many thanks!
Edu.
Logged
*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Eos 400d ( Rebel XTI )
« Reply #1763 on: 12 / June / 2013, 03:22:24 »
Quote from: eduperez on 12 / June / 2013, 03:08:43
@Sergei / @0xAF:

I am experiencing random camera lock-ups, that I cannot fix myself, and would like to hear your opinion on this. As far as I know, the symptoms when this happens are:

* Just after a shot has been taken, all buttons stop responding, and the display does not show our overlay.
* Camera can take another photograph, however (but it does not get to the CF card)
* Finally, the display goes off, and the camera is completely locked (it cannot even be turned off).

In 400plus, we always overlay something on the display, so my first suspect was the overlay code; I commented out that part, and it seems to work (but you can never be sure with random bugs). This would confirm that the source of the problem is in the overlay code.

Now, how can it be possible that we always overlay something, but I see nothing in the display? So, my next suspect is the pointer to the display that we receive: if we received a wrong pointer, we would be writing somewhere else in the memory, and that could explain the lock-up.

I tried to log the value that we receive in that parameter, and it seems to be constant (I could not reproduce the issue and see what value we received when it happens, however); there is also that weird constant value that we add to the pointer.

And this is all I know about this issue... I have been banging my head against the code for weeks, but I cannot find anything else.  Do you have any ideas, please?

Many thanks!
Edu.

Hm, I should try to simulate the problem too... Perhaps in the end of the week I'll get some free time to play with it.
About the pointer, it will be always the same, do not worry about it. The offset which we add to the pointer, is because this pointer  points to a structure, and we use some member of this structure (hence we offset from the beginning of the structure).

It's strange that commenting the overlay code fixes the problem. I would not suspect it, but I should check it out to be sure. The actual changing of the VRAM stuff is not the problem, but something that uses the same hardware, or other hardware somehow related (IRQs/MPU/some bus) could interfere...

I will have a look later this week.
Logged
// AF
*

Offline Sergei

  • ***
  • 114
Re: Eos 400d ( Rebel XTI )
« Reply #1764 on: 12 / June / 2013, 07:22:07 »
Have you tried to use static value for display_overlay() in hack_TransferScreen()?
Something like this:  display_overlay((uint8_t*)(0x12345 + 0x78)); Where "0x12345" is a integer value from r3 which is now hard coded to prevent to use different pointer in display_overlay() if hack_TransferScreen() receives different one.
   Or maybe you can move display_overlay() to *hack_invert_olc_screen().
Code: [Select]
void *hack_invert_olc_screen1(char *dst, char *src, int size) {
        display_overlay(src);
        if ( settings.invert_olc && (FLAG_GUI_MODE == GUIMODE_OLC)) {
                while (size--) {
                        *dst++ = olc_colors_map[settings.invert_olc] - (*src++);
                }
                return dst;
        }

        return memcpy(dst, src, size);
}

void *hack_invert_olc_screen2(char *dst, char *src, int size) {
        if ( settings.invert_olc && (FLAG_GUI_MODE == GUIMODE_ACTIVESWEEP_OLC)) {
                while (size--) {
                        *dst++ = olc_colors_map[settings.invert_olc] - (*src++);
                }
                return dst;
        }

        return memcpy(dst, src, size);
}
And change those two lines in init.c:
        cache_fake(0xFF92C5D8, BL_INSTR(0xFF92C5D8, &hack_invert_olc_screen1), TYPE_ICACHE);
        cache_fake(0xFF92C5FC, BL_INSTR(0xFF92C5FC, &hack_invert_olc_screen2), TYPE_ICACHE);
« Last Edit: 12 / June / 2013, 15:44:30 by Sergei »
Logged
*

Offline eduperez

  • ****
  • 426
Re: Eos 400d ( Rebel XTI )
« Reply #1765 on: 18 / June / 2013, 10:12:27 »
May thanks to both 0xAF and Sergei for your help; I will try your advice and report back.
Logged
*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Eos 400d ( Rebel XTI )
« Reply #1766 on: 18 / June / 2013, 13:14:28 »
Quote from: eduperez on 18 / June / 2013, 10:12:27
May thanks to both 0xAF and Sergei for your help; I will try your advice and report back.

Sorry Edu, I was out of reach in the weekend, I cannot promise my free time soon... I will do my best, though!
Logged
// AF
*

Offline eduperez

  • ****
  • 426
Re: Eos 400d ( Rebel XTI )
« Reply #1767 on: 20 / June / 2013, 01:45:07 »
Quote from: 0xAF on 18 / June / 2013, 13:14:28
Sorry Edu, I was out of reach in the weekend, I cannot promise my free time soon... I will do my best, though!

No reason to be sorry... I understand, and I cannot complaint!
Logged
*

Offline eduperez

  • ****
  • 426
Re: Eos 400d ( Rebel XTI )
« Reply #1768 on: 20 / June / 2013, 02:05:16 »
Well, this is weird...

I am intercepting the display refresh using the traditional method (cache hacks are scheduled for next version):
Code: [Select]
TransferScreen = my_TransferScreen;

And my_TransferScreen is just this piece of code:
Code: [Select]
int my_TransferScreen(int r0, int r1, int r2, int r3, int a, int b, int c, int d) {
    display_overlay((uint8_t*)(r3 + 0x78));

return TransferNormalScreen(r0, r1, r2, r3, a, b, c, d);
}

Now, the fun part is at display_overlay:
Code: [Select]
void display_overlay(uint8_t *vram_address) {
char buffer[LP_MAX_WORD];

if (FLAG_GUI_MODE == GUIMODE_OLC && AE_IS_CREATIVE(DPData.ae)) {
int current_cmode = get_current_cmode();

if (status.msm_active)
bmp_printf(vram_address, FONT(FONT_SMALL, COLOR_BLACK, COLOR_GRAY),  35,  96, "[***]");
else if (status.cmode_active && current_cmode != CMODE_NONE)
bmp_printf(vram_address, FONT(FONT_SMALL, COLOR_BLACK, COLOR_GRAY),  16,  96, "%s", cmodes_config.names[current_cmode]);

if (status.fexp && DPData.tv_val != TV_VAL_BULB)
bmp_printf(vram_address, FONT(FONT_SMALL, COLOR_BLACK, COLOR_GRAY), 138,  32, "#");

if (settings.autoiso_enable && (DPData.ae != AE_MODE_M || DPData.tv_val != TV_VAL_BULB))
bmp_printf(vram_address, FONT(FONT_SMALL, COLOR_BLACK, COLOR_GRAY), 237,  14, "%s", AUTOISO_AUTO);

if (DPData.wb == WB_MODE_COLORTEMP)
bmp_printf(vram_address, FONT(FONT_SMALL, COLOR_BLACK, COLOR_GRAY),  50, 138, "%d", DPData.color_temp);

if (DPData.ae_bkt) {
ec_print(buffer, DPData.ae_bkt);
bmp_printf(vram_address, FONT(FONT_SMALL, COLOR_BLACK, COLOR_GRAY), 224,  96, "%s", buffer);
}

#ifdef RELEASE
bmp_printf(vram_address, FONT(FONT_SMALL, COLOR_BLACK, COLOR_BLUE), 148, 0, LP_WORD(L_P_400PLUS));
#else
bmp_printf(vram_address, FONT(FONT_SMALL, COLOR_BLACK, COLOR_RED ),  20, 0, LP_WORD(L_A_WARNING));
#endif

if (*display_message) {
if(timestamp() < message_timeout)
bmp_printf(vram_address, FONT(FONT_SMALL, COLOR_WHITE, COLOR_BLACK),  16, 228, display_message);
else
*display_message = '\0';
}
}
}

With that code, bad things happen: I cannot take more than a couple dozen photographs before the camera locks. If I just comment out the first line (where TransferScreen is intercepted), then everything seems to work nicely; so far so good, problem seems to be here.

I suspected we could be writing to the display in a bad moment, so I added some code, at the end of display_overlay, but inside the "if (FLAG_GUI_MODE == GUIMODE_OLC && AE_IS_CREATIVE(DPData.ae))" condition, to check whether the display was off, and make the camera emit a beep in that case (notice that the display is checked after writing to it, we are always writing to the display).

Well, guess what? Yes, I hear the accusing beep now and then, but one hundred photographs later the camera hasn't failed once.  So, adding some innocent code inside display_overlay seems to fix the issue, but I haven't the slightest idea of why...
Logged
*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Eos 400d ( Rebel XTI )
« Reply #1769 on: 20 / June / 2013, 03:01:04 »
Quote from: eduperez on 20 / June / 2013, 02:05:16
Well, guess what? Yes, I hear the accusing beep now and then, but one hundred photographs later the camera hasn't failed once.  So, adding some innocent code inside display_overlay seems to fix the issue, but I haven't the slightest idea of why...

Sounds like a race condition ?!?... Perhaps a semaphore can solve it.
Either our own semaphore, or we find a semaphore for the display and rely on it.
Logged
// AF
Pages: 1 ... 172 173 174 175 176 [177] 178 179 180 181 182 ... 188   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal