Well that explains why I could not find anything on the chip. I am somewhat familiar with the Atmel line but know nothing of this one. Glancing over the specs it does look like a fairly respectable little MPU (perspective: it is as powerful as my first computer ... Commodore 64). There is a lot of potential in this unit. I did not do much in the way of tracing circuits but what there is does not seem to be too complicated.
The simplest scenario is that if the the power source is the camera then the device goes in to 'RUN' mode. If power comes from the USB then the device goes into 'PROGRAM' mode. Then there would need to be logic to determine which was the default mode if there were power on both interfaces. The 'PROGRAM' mode might not be a full boot loader but only replace a parameter table in Flash. It might also remain mute until it seems a particular byte sequence. This could be an interesting little project.
At this point it does not work with my lens of choice so I have ordered the Viltrox from Amazon to see if that has any better luck. I did send an email to Neewer telling them of my disappointment with their device and asking about updating the firmware. I had a response last night requesting specific order information. I sent that and am now in wait and see mode.
Most of the documentation I've seen for the STM32 indicates that typical USB DFU bootloaders for this device enter program mode when powered on with a USB host connected. At that point they should at least enumerate on a USB bus - but I'm not seeing it even enumerate.
However, looking at the way it does it (tries multiple clock rates first) it might anger some USB hubs that work fine with most hardware, so I'm going to try other cables/hubs to see if they behave differently.
If a way can be determined to get it into DFU mode it might be possible to readback the current firmware - and then it would be possible to start work on replacing the firmware.
To Meike/Neewer's credit, it makes sense that they don't have a firmware updater available yet since the device JUST was released and thus there's only the initial factory firmware available for it. It's pretty common for the initial firmware for a device never to be released in an updater as it makes it a bit more difficult for competitors to reverse engineer. This is even the case for mobile phone firmwares from some manufacturers (Samsung NEVER makes firmware packages for their Android devices public, mortal users outside of service centers are always supposed to use OTAs, but people have figured out how to find the Odin update packages for devices in most cases, however I've never seen an Odin package for any device's "factory" firmware that wasn't created by a few enterprising hackers pulling the firmware off of 2-3 shipped devices. As to 2-3 - need to use a rooted /system image to pull a clean kernel, then need a kernel with insecure ADB to pull a clean /system image.)
Also potentially useful, some additional docs on STM32 DFU:
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Attachments/18225/AN2606.pdf
By the definitions given in that document, this is a "medium-density" STM32F103xx device (64 kB flash)
It implies that BOOT0 must be high for the device to boot into "System memory" DFU mode - but other docs indicate "System memory" DFU might not exist on this device - so not sure.
It's a VQFPN36 package from the looks of it, pinout for this package is on page 27 of the datasheet from a previous post I made. BOOT0 is pin 35, pin numbers are counterclockwise from 1, not sure what designates "1" on this chip. So 35 is two pins clockwise from 1. Assumption is that the diagram in the datasheet is aligned so that the text on the chip is "normally" readable in that orientation, e.g. pin 1 is the top of the left row of pins. This would make pin 35 the second from the left on the top. In your circuit board image, the STM32 is rotated 90 degrees CCW, making pin 35 the second from the bottom of the left row in that image.
Edit: Reading further, it seems like system memory bootloader only supports USART. So that's consistent with some of the USB DFU references indicating that USB bootloaders on some devices need to reside in user flash. As a result, since user flash determines whether to go to normal operation or stay in bootloader mode, we don't know what the criteria are for bootloader mode. I'm really hoping that it's just a result of me using a hub/cable it didn't like, because if we need "magic tricks" to enter DFU mode this could be tough.
Edit 2: However, if it can be determined how to get BOOT0 high, and assuming USART1 is wired to the E-mount serial lines, it may be possible to enter serial bootmode for readback/unbricking.
Detailed reference manual for the family that includes STM32F103xx:
http://www.st.com/web/en/resource/technical/document/reference_manual/CD00171190.pdf (Warning: LARGE - 1128 pages, the datasheet I linked to a few posts previously is only 117).
