IXUS160/ELPH160 Porting attempt - page 16 - DryOS Development - CHDK Forum
supplierdeeply

IXUS160/ELPH160 Porting attempt

  • 497 Replies
  • 120817 Views
*

Offline srsa_4c

  • ******
  • 3904
Re: IXUS160/ELPH160 Porting attempt
« Reply #150 on: 01 / August / 2015, 18:15:22 »
Advertisements
Additionally, there is a bug with power up mode detection, camera always start up on REC mode.
See this. So, maybe the following could work?
Code: [Select]
*(int*)(0x2A04 + 4) = (*(int*)0xC022F484)&0x20000 ? 0x400000 : 0x200000;
Digital IS looks like raw hook is not being called. shoot() shoots twice, raw hook always times out. remote hook is also not called.
That's what I was expecting. I think the digital IS code path is in the firmware's SsGISCaptureSeq.c routines, likely in sub_FFAD80B0.
On the other hand, digital IS mode operates the sensor in quarter resolution (probably binned) mode, so RAW would not work with current CHDK. The mode also shoots continuously while the shutter is held down and outputs a single averaged JPEG at the end.
For now, it's probably better to leave it as it is.

*

Offline reyalp

  • ******
  • 11897
Re: IXUS160/ELPH160 Porting attempt
« Reply #151 on: 01 / August / 2015, 18:34:48 »
On the other hand, digital IS mode operates the sensor in quarter resolution (probably binned) mode, so RAW would not work with current CHDK. The mode also shoots continuously while the shutter is held down and outputs a single averaged JPEG at the end.
For now, it's probably better to leave it as it is.
Note that it's not just raw and shoot hooks that break if the hook isn't called the, the shoot() function is also broken because it doesn't detect that the shot was taken.

There should probably be a CAM_DISABLE_RAW_IN_DIGITAL_IS if usable raw data is not available. It wouldn't hurt to set this if the hook isn't called at all, although it doesn't fix the problem.

Someone should also check whether valid raw is captured in auto and low light modes, and define the appropriate CAM_DISABLE_RAW_IN_* defines if not.
Don't forget what the H stands for.

*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #152 on: 02 / August / 2015, 04:48:55 »
@adong or anybody else with the camera
I have a few requests and suggestions.

- Can somebody test the camera in playback mode with chdkptp? Do you get the same image as the one on the LCD?
- Please run the hooktest script in P mode and in "Digital IS" mode. The script's description is here.

If you get bad display in the chdkptp test, try replacing

Code: [Select]
// guessed from sub_FF84E884
DEF(viewport_fb_d, 0x00003314)
with
Code: [Select]
// 0xff883c54 (0x32d4), 0xff883c90 (0x54); see ixus140 0xff0a7858, 0xff0a7890
DEF(viewport_fb_d, 0x00003328)
in stubs_min.S .

I think 0x3314 is an eventflag (0x32d4 + 0x40, see the code right before 0xff883074).

You beat me to it, noticed this morning when trying to port ixus170 that it was not working haha

I also tested the power on fix and it works, sorry for not understanding the first time  :(
@nafraf: thanks for including it in trunk!
« Last Edit: 02 / August / 2015, 04:55:25 by adong »

Re: IXUS160/ELPH160 Porting attempt
« Reply #153 on: 02 / August / 2015, 09:26:06 »
Because of the dual partition the disk became full quite quickly.
As waterwingz mentioned, new ports no longer support dual partitions.

Yes, the crash happened after I posted the first question, but before waterwingz answered...
Quote
You mentioned Licks, so I assume you're on Linux. If all utilities fail, you can make a card bootable manually, see the Linux section(s) here: http://chdk.wikia.com/wiki/Prepare_your_SD_card
Thx, that will help.

Quote
So there is possibly an error in the code when there is no space left on the card...
Quote
I think I have encountered issues when the card is almost full and CHDK RAW is enabled: in this case, the Canon firmware may encounter an unexpected out-of-space situation which triggers a Canon error. That may have been the crash you were experiencing.
It was trying to write raw indeed. But the error message was flashed in chdk.

Quote
I assume that the crash itself did not cause the lens to move.
When you tried re-starting the cam afterwards, the camera tried to retract the lens, but it failed.
Actually in the crash itself, the camera extended the lens to far to a point it couldn't retract. I tried rebooting normally a couple of times, but it kept giving the lens error and not retracting. I left it on its back overnight. Next morning I retried and it retracted normally! As my washing machine was on and it vibrates the floor a lot, it might have shaken the lens motor back or such. Or I just got lucky...

Quote
I was lucky in fixing that, but a second attempt to boot chdk bricked it completely...
Quote
can you detail what happened at that second attempt and what does the "completely" bricked camera do since then?

I recreated the sd card with again the two partitions (did not know yet it couldn't work), and tried my second camera. That again crashed in raw mode, same thing, but now the camera went dead, as in permanently shut off.

When the disk became full, the crash might have overwritten the system firmware in memory. It should not happen, but I can't explain otherwise why both cameras broke in such a way. (I did return the dead one and Canon sent me another). The other seems fine so far, going to try to create fat32 image now.


Re: IXUS160/ELPH160 Porting attempt
« Reply #154 on: 02 / August / 2015, 09:56:55 »
Where can i find the latest chdk for ixus160? I previously used the built in the post (in the http://chdk.setepontos.com/index.php?topic=12321.msg123174#msg123174 message), but is there a newer better built available?

And will chdkptp work out of the box with this build?
« Last Edit: 02 / August / 2015, 13:07:10 by Scannerall »

*

Offline srsa_4c

  • ******
  • 3904
Re: IXUS160/ELPH160 Porting attempt
« Reply #155 on: 02 / August / 2015, 17:25:05 »
Actually in the crash itself, the camera extended the lens to far to a point it couldn't retract.
That's rather nasty and I can't really explain it... Something may have corrupted the RAM. Which would also "explain" that:
Quote
I recreated the sd card with again the two partitions (did not know yet it couldn't work), and tried my second camera. That again crashed in raw mode, same thing, but now the camera went dead, as in permanently shut off.
Quote
the crash might have overwritten the system firmware in memory.
CHDK doesn't have routines that write the flash, but the Canon firmware does write into the flash when shutting down. If the RAM was badly corrupted then it might be possible that unintended parts of the flash memory were overwritten.

Anyway, 2 bricks out of two seems more than just coincidence.

I tried the scenario on one of my cameras (enabled DNG on a card with 2 MB free space). CHDK used up all space on the card, and the camera could not save the JPEG. It did not shut down, it displayed "memory card error" instead.

You also mentioned a CHDK error message: we don't have much of those and I don't think you'd be seeing one of them in a scenario like this.

@adong
Can you please remove the test release binaries?

General note:
I think we should disable RAW/DNG when there's not enough space on card...

Re: IXUS160/ELPH160 Porting attempt
« Reply #156 on: 02 / August / 2015, 17:51:32 »
I actually had about 22 MB left on the card and the problem occured when writing the Dng after it wrote the/a jpg. I am actually not sure about the message being from chdk, so it could be that canon reported the card full, but chdk tried to continue writing.
I have tried the same built successfully now on a fat32, thx for the link, I just used fdisk and echo to create the bootable disk. Now it seems to work ok.

As I started this in the hope of doing a bookscanner: where can I find the most current built and will it work with chdkptp?

*

Offline reyalp

  • ******
  • 11897
Re: IXUS160/ELPH160 Porting attempt
« Reply #157 on: 02 / August / 2015, 23:41:52 »
I actually had about 22 MB left on the card and the problem occured when writing the Dng after it wrote the/a jpg. I am actually not sure about the message being from chdk, so it could be that canon reported the card full, but chdk tried to continue writing.
I have tried the same built successfully now on a fat32, thx for the link, I just used fdisk and echo to create the bootable disk. Now it seems to work ok.
Added this to http://chdk.wikia.com/wiki/Camera_failures_suspected_to_be_caused_by_CHDK

When you say
Quote
I recreated the sd card with again the two partitions (did not know yet it couldn't work), and tried my second camera. That again crashed in raw mode, same thing, but now the camera went dead, as in permanently shut off.
Do you mean the camera shows the same symptoms as the first one (lens error?) Or does it simply not power on at all? In the latter case, I assume you've tried removing the battery and/or external power supply.

Another question, do you have any idea what shooting mode the cameras were in? (Auto, P, some scene mode...?)

Quote
As I started this in the hope of doing a bookscanner: where can I find the most current built and will it work with chdkptp?
Given the apparent destruction of two cameras, publicly distributing builds may not be a good idea. However, since you don't seem afraid I'll pm you a link for trunk r4201. I don't know how much this differs from the previously posted builds. No ixus160 specific code has been changed since nafrafs original checkin.

My impression is that chdkptp functionality should be generally working.
Don't forget what the H stands for.


*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #158 on: 03 / August / 2015, 03:31:58 »
I removed all links to my builds.

*

Offline srsa_4c

  • ******
  • 3904
Re: IXUS160/ELPH160 Porting attempt
« Reply #159 on: 03 / August / 2015, 15:32:21 »
I removed all links to my builds.
Thanks. We'll need to figure out whether this issue is a porting problem, or it's caused by something like a stack overflow. To be honest, the code_gen'd code looks okay to me, so I'd rather think that
- one of the fw addresses we use is wrong and/or
- Canon has changed one of the fw functions we're relying on and/or
- we're overusing stack somewhere
...

@nafraf
If you have time, can you check the power-up fix, and if it's working, commit it?

 

Related Topics