CHDK PTP interface - page 121 - General Discussion and Assistance - CHDK Forum supplierdeeply

CHDK PTP interface

  • 1205 Replies
  • 247219 Views
*

Online reyalp

  • ******
  • 11899
Re: CHDK PTP interface
« Reply #1200 on: 27 / May / 2019, 23:25:58 »
Advertisements
Here's a patch that finds the ptp buffer size function for pre-digic 6 dryos and vxworks.

It seems to work for all but the very oldest vxworks (ixus30 - ixus50, ixus700 and s2is) which seem to use a constant 0x40000 instead of a function.

The function to get the buffer address (d10 FF9F6B28, a540 FFE57498) seems a bit more complicated to match, so any clever ideas for that are welcome.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3906
Re: CHDK PTP interface
« Reply #1201 on: 01 / June / 2019, 16:21:55 »
The function to get the buffer address (d10 FF9F6B28, a540 FFE57498) seems a bit more complicated to match, so any clever ideas for that are welcome.
No code this time, but
Vx:
- [ObjMethdRW]Error:PrepareSubstancePTPObject, Open[%s] reference though not all cams have it
- ObjMethdRW.c string reference can still help with those cams that don't have the above string
both:
- get_ptp_buf_addr references get_ptp_buf_size
- get_ptp_buf_addr also references one of the commemman routines
- bic instruction

*

Online reyalp

  • ******
  • 11899
Re: CHDK PTP interface
« Reply #1202 on: 02 / June / 2019, 02:24:10 »
Thanks. I ended up matching the instruction sequence with get_ptp_buf_size and bic. It seems work on all cams except the very old vxworks that don't have get_ptp_buf_size (which is fine, there's few enough that they could be dealt with manually if needed)
Don't forget what the H stands for.

*

Online reyalp

  • ******
  • 11899
Re: CHDK PTP interface
« Reply #1203 on: 03 / June / 2019, 02:22:06 »
Here's an initial patch that allows use of either the canon PTP buffers or heap malloc'd buffers. It also includes the earlier sig finder patches.

* ptp.c is compiled as platform code, instead of generic
* camera.h define CAM_PTP_USE_NATIVE_BUFFER uses the canon buffer. Requires get get_ptp* functions
* New ptp.c function get_ptp_temp_buf takes the total transfer size, and returns a buffer and buffer size. If using CAM_PTP_USE_NATIVE_BUFFER, the max buffer size is from get_ptp_file_buf_size, otherwise it's the half the largest free block.
* free_ptp_temp_buf frees the buffer, if using heap buffer.
* Code that *only* needs a temporary buffer (flush_recv_ptp_data and PTP_CHDK_UploadFile) uses get_ptp_temp_buf and data->recv_data directly
* Other code uses recv_ptp_data, which uses get_ptp_temp_buf only if the camera is using CAM_PTP_USE_NATIVE_BUFFER and otherwise uses the destination buffer.

The last two items are to unnecessary buffering that could be problematic on low memory cameras that don't use the native buffer.

There are still some loose ends to clean up, but it does seem to solve the problems on D10, and not break cameras using the heap buffer. I still need to make some easy to run tests. I'd also like to get rid of the last of the global buf_size logic for camera->pc transfers too.

edit:
Oops, missed some files in the first patch. Update attached.
« Last Edit: 03 / June / 2019, 02:25:57 by reyalp »
Don't forget what the H stands for.


*

Online reyalp

  • ******
  • 11899
Re: CHDK PTP interface
« Reply #1204 on: Yesterday at 02:31:50 »
I spent some more time trying to understand the issues on A540

The crash is "Assert BulkTrns.c line 1544", which happens in sub_FFE4DBDC
This is called from sub_FFE50B50, which comes from some table of BulkTrns related functions at FFE50BAC. The condition being checked in the assert isn't obvious to me.

The crash happens when
1) data->recv_data is called more than once
2) total size is (512*n) - 11 to (512*n) - 1 i.e. 0x...1f5 through 1ff.

Additionally, when using the native buffer (maybe any uncached) a stalled connection happens for something like 512*n to 512*(n+1)-13. Larger sizes appear to be OK, though I haven't checked exhaustively.

These problems happen even using native PTP operations, so
Code: [Select]
!newfi2={ Filename="BAD.DAT", ObjectFormat=0xbf01, ObjectCompressedSize=1024*256+512-11}
!return con:ptp_send_object_info(newfi2)
!return con:ptp_send_object(('x'):rep(newfi2.ObjectCompressedSize))
Triggers the assert, and size 1024*256+512 triggers the stalled connection, while 1024*257 works fine.  I previously thought native operations weren't affected, but my test was incorrect. This is reproducible without CHDK running.

Note as I posted earlier some cameras require A/ on the path and crash with an different assert if it is not present. Others, including A540 (and likely all vxworks cameras) crash if it is present.

Also, although get_ptp_buf_size(4) returns 512K, the camera divides this value by 2 for transfers. I previously verified by hooking data->recv_data and logging the values that it's really doing 256K chunks. Based on the total ComMemMan size and other code, it seems likely the actual buffer is 512K, so why the firmware uses size/2 is unclear.

With CHDK, the problem will only occur if the total transfer is larger than 1/2 free memory and one of the magic sizes. Using a fixed 256K buffer, the following reproduce it

file upload
Code: [Select]
!fh=io.open('TEST.DAT','wb') fh:write(('x'):rep(1024*255+1525-14)) fh:close()
u test.dat
The -14 accounts for the file name and file name length.

Flushed script message (no script running):
Code: [Select]
!con:write_msg(('x'):rep(1024*255+1525))

The problem also occurs if the first read isn't a multiple of 512, e.g. if the first recv_data is 4000, it fails at 4085.

tl;dr
1) I'd be interested to see results on other vxworks cameras for the SendObject test.
2) This doesn't seem fixable for A540, and the current trunk style code doesn't seem worse than other options
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3906
Re: CHDK PTP interface
« Reply #1205 on: Yesterday at 19:00:26 »
Code: [Select]
!newfi2={ Filename="BAD.DAT", ObjectFormat=0xbf01, ObjectCompressedSize=1024*256+512-11}
!return con:ptp_send_object_info(newfi2)
!return con:ptp_send_object(('x'):rep(newfi2.ObjectCompressedSize))
Triggers the assert, and size 1024*256+512 triggers the stalled connection
Same experience (crash, hang) on s80 (older vx).
No problem executing with either size on a460 (late vx), file gets created in both cases.

 

Related Topics