CHDK PTP interface - page 81 - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: 1 ... 76 77 78 79 80 [81] 82 83 84 85 86 ... 125   Go Down

CHDK PTP interface

  • 1240 Replies
  • 406369 Views
*

Offline srsa_4c

  • ******
  • 4437
Re: CHDK PTP interface
« Reply #800 on: 30 / June / 2012, 18:20:39 »
Advertisements
I have also experienced some weirdness when I tested the PTP liveview stuff on the A410, but I haven't tested it thoroughly. In short: I've been unable to upload the whole (trunk) installation package over CHDK-PTP (using the latest chdkptp GUI, with neither CHDK 1.0 nor CHDK 1.1 on the camera). A particular file which always caused assert was CHDK/LUALIB/drawings.lua . More investigation would be needed, I guess. The romlog shows an assert in BulkTrns.c line 0x5d8, task: tPtpTrsnpV.
Separate (long standing) issue is the extreme slowness of the file upload on USB1.1 cameras (pause of multiple seconds after each file).
Logged
*

Offline reyalp

  • ******
  • 13621
Re: CHDK PTP interface
« Reply #801 on: 30 / June / 2012, 18:51:10 »
I'm not getting an assert with either messages or file upload. The ptp task gets stalled.

However, I wrote a script that sends messages from with every length from 1 to N and that seems to be crashing in a different way.

edit:
Here's the script. Getting several unexplained results, but it looks like D10 gets a similar issue at length=500

Code: [Select]
chdkptp -c -i
!m=require'msgtest'
!m.load()
!m.test(<start lenght>,<optional max length>,<optional increment>)

edit:
Updated, you can now specify increment

edit:
this appears to be related to the bits of the data length ending in 1f4  :o
« Last Edit: 30 / June / 2012, 19:27:02 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 13621
Re: CHDK PTP interface
« Reply #802 on: 30 / June / 2012, 21:55:20 »
Filename length may be a red herring.

On my a540, both PTP_CHDK_WriteScriptMsg and PTP_CHDK_UploadFile seem to hang for ~5 sec in recv_ptp_data

Stuffing the filename length into a global displayed with misc debug vals shows the right.

Attached is patch with debug code I'm using to check this.

Another oddity: on D10 0x1f4 is bad, on a540 is not. Subsequent values (3f4, 5f4 etc) are bad on both.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4437
Re: CHDK PTP interface
« Reply #803 on: 30 / June / 2012, 22:14:37 »
Quote from: reyalp on 30 / June / 2012, 18:51:10
However, I wrote a script that sends messages from with every length from 1 to N and that seems to be crashing in a different way.
Just a quick test: problematic lengths on the A410: 0x74, 0xb4, 0xf4, 0x134 (and so on, I guess). The assert (same as above) comes on the next ptp attempt.
Logged
*

Offline reyalp

  • ******
  • 13621
Re: CHDK PTP interface
« Reply #804 on: 01 / July / 2012, 03:14:17 »
srsa_4c
Interesting the interval is smaller. IIRC, usb1 uses smaller packets for bulk data ?


Some other random observations:
Examining ptp_data->recv_data, it looks like it returns 0 on success, and various values on error. When this particular problem happens, it returns 1. recv_ptp_data in ptp.c doesn't check the status

On d10
00116180: [PTPState] PTP_Unexpected Type=0 STATE=5 EVENT=16
seems to appear in camera log when this happens. Unfortunately, it's not clear where the function that produces this string is called from.

There are references in the firmware (both a540 and d10) to "A/BulkTrns.Log". On a540 it looks like the eventprocs

PTPRspnd.StartTransportLog
PTPRspnd.StopTransportLog
PTPRspnd.ShowTransportLog
PTPRspnd.ClearTransportLog

should relate to this. However, after registering them with RegComEventProc, I wasn't able to get them to do anything. They don't seem to exist on d10.

Logged
Don't forget what the H stands for.
*

Offline msl

  • *****
  • 1276
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: CHDK PTP interface
« Reply #805 on: 01 / July / 2012, 08:44:41 »
Quote from: reyalp on 20 / June / 2012, 13:10:59
Minor versions (like 2.0 to 2.3) are supposed to be backward compatible, so it should be safe for ptpCamGui to start if the minor version is greater than what it knows about.

Yes, I know. I've made a little update for ptpCamGui. Now the gui will only check the major version.

msl
Logged
CHDK-DE:  CHDK-DE links
*

Offline reyalp

  • ******
  • 13621
Re: CHDK PTP interface
« Reply #806 on: 01 / July / 2012, 16:41:01 »
I had the idea that if the problem is triggered by reading a particular size, we could  detect that size and force multiple calls to data->recv_data, so no single call uses the magic size. Turns out, this doesn't help :(

Another observation: On D10, size 0x1F4 behaves slightly differently from the larger problem values. It appears to hang in data->get_data_size, which then returns 0. For larger values, get_data_size returns the correct value and the hang is in recv_data. I suppose this relates to the fact that ox1F4 is ok on a540...

edit:
The [PTPState] PTP_Unexpected Type=0 STATE=5 EVENT=16  message comes from the get_data_size case, not recv_data
« Last Edit: 01 / July / 2012, 19:00:41 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 13621
Re: CHDK PTP interface
« Reply #807 on: 02 / July / 2012, 01:44:48 »
On D10, I narrowed down where the error is returned from in data->recv_data (sub_FF9FA258) to the bne at FF9FA37C. The hang seems to happen in the preceding call to sub_FF869A1C__KerFlag_c (some kind of synchronization object timing out, I think)

Some of the preceding code seems to be related to the unknown parameter to recv_data that we always set to zero. I tried putting in a 1, but that didn't help.

edit:
testing error, setting the unknown param to 1 crashes very promptly when you try to use ptp. No surprise there ;)
« Last Edit: 02 / July / 2012, 03:11:46 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3377
    • Photos
Re: CHDK PTP interface
« Reply #808 on: 02 / July / 2012, 04:24:19 »
Quote from: reyalp on 02 / July / 2012, 01:44:48
On D10, I narrowed down where the error is returned from in data->recv_data (sub_FF9FA258) to the bne at FF9FA37C. The hang seems to happen in the preceding call to sub_FF869A1C__KerFlag_c (some kind of synchronization object timing out, I think)

Some of the preceding code seems to be related to the unknown parameter to recv_data that we always set to zero. I tried putting in a 1, but that didn't help.

edit:
testing error, setting the unknown param to 1 crashes very promptly when you try to use ptp. No surprise there ;)

Out of curiosity, does the problem still happen using the Rasberry PI version you posted about in another thread?
If so that would pretty much make it a firmware problem, as your research seems to indicate. Or at least a problem in the way CHDK is using the firmware.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline reyalp

  • ******
  • 13621
Re: CHDK PTP interface
« Reply #809 on: 02 / July / 2012, 04:33:48 »
Quote from: philmoz on 02 / July / 2012, 04:24:19
Out of curiosity, does the problem still happen using the Rasberry PI version you posted about in another thread?
If so that would pretty much make it a firmware problem, as your research seems to indicate. Or at least a problem in the way CHDK is using the firmware.
It does the same thing from the pi. Not sure it's really any different than the linux laptop I already tested though...
Logged
Don't forget what the H stands for.
Pages: 1 ... 76 77 78 79 80 [81] 82 83 84 85 86 ... 125   Go Up
« previous next »
 

Related Topics