Welcome
Welcome to goprouser

You are currently viewing our boards as a guest, which gives you full access to view most discussions and access.. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. In addition, registered members also see less advertisements. Registration is fast, simple, and absolutely free, so please, join our community today! Any issues email goprousergroup@gmail.com

GoPro brick revival?

The Interface BUS or Rear Port. Discuss projects or creative uses.

GoPro brick revival?

Postby Kilrah » Mon Sep 19, 2011 9:20 pm

Hi,

This would have to be more in a "Firmware" forum than the "Bus" one, but there's no such section, and there has been a lot of firmware dicsussion in the original Bus thread...

Anyway, I have a Gopro HD that got bricked a couple of months ago during a firmware upgrade due to a silly mistake from me, and which doesn't turn on anymore at all (at least in a visible manner). I contacted GoPro support, who after (few) support steps advised me to send the camera in for support. I was hoping for a procedure to reflash it through some kind of bootloader instead of doing it from the main application like the "standard" way does, but it seems such a method doesn't exist.
I can't send my camera in as it was heavily modified, with an integrated 2.4GHz wireless video transmitter, and a PIC that I was using to automate the Live video out procedure before the firmware upgrade allowing it came out... They'd probably have a good laugh seeing this:

Image

So as I just found these discussions and have nothing to lose anyway (already have another camera) I wired up the UART, and checked the output:

Code: Select all
audio tasks init done
DRAM_DSP_BASE register setting is 0x7E007F
Initialize cavlc task
Format cache 385048 1104 1160
bits buffer addr = 0xC33CA7E0
desc buffer is zero or negative
AMBA_YUVMON: the YUV device didn't support auto detect
allocate tsmux_par_t size 3280
allocate data_tracksize 96
allocate tsmux_misc_t 224
allocate tsmux_par_t size 3280
allocate data_tracksize 96
allocate tsmux_misc_t 224
AMBA tsmux was inited before, maybe avchd already init
register illegal video signal id
Recoder module init OK
-----------------c2305ce0 32
-----------------c2305d00 32
========== cavlc encode init ===========
========== cavlc encode init ===========
Player state transition manager ready
Player video pipeline controller ready
Playback video manager ready
========== cavlc decode init ===========
DeMux manager ready
Player photo pipeline controller ready
Playback photo manager ready
DeMux manager ready
Player sound pipeline controller ready
Playback sound manager ready
DeMux manager ready
Player thumb pipeline controller ready
Playback thumb manager ready
DeMux manager ready
State transition manager ready, mbx_id = 5
CAVLC Boot.........
Host control manager ready
@@@@@@@@@@@@@@@  DemoApp start to init  --- 474
--- ARM UNDEFINED INSTRUCTION EXCEPTION ---
Oops: CPU Exception!
pc : [<c0406258>]    lr : [<c03197a4>]
sp : c0566eb0  ip : 00000000  fp : 00000000
r10: 00000000  r9 : 00000000  r8 : 00000000
r7 : 00000000  r6 : 00000000  r5 : 00000000
r4 : 00000000  r3 : c03c6f54  r2 : fffffff8
r1 : c0566eac  r0 : 00000000
Flags: nZcv
IRQs on  FIQs on  Mode SVC_32


This does indeed look like a corrupted image, unfortunately it seems to be quite early in the startup process. After this output the camera freezes, and it's necessary to remove the battery to retry. No response to the shell obviously.
Compiled from my reading of the big thread I found about the autoexec.ash and firmfl tricks, and tried to throw the v01.01.54 image along with the following autoexec.ash on the card:
Code: Select all
firmfl prog d:\firmware.bin


hoping that the script interpreter would read it before the crash, but unfortunately it doesn't seem so, UART output is identical.

Does anyone have an idea on how to revive it, experimented with the JTAG port or something else?
Kilrah
 
Posts: 25
Joined: Mon Sep 19, 2011 9:01 pm

Re: GoPro brick revival?

Postby mcappel » Tue Nov 08, 2011 3:53 pm

May be sounds stupid and you did it before. I had a Gopro (not customized as yours) with exactly the same behavior, dont know about the booting log, but after trying with Gopro support without any sucess, and reading another post that someone solve the problem by inserting the bagpack, i guest that it should be a problem with the bus port, I clean it and "Eureka" it is working again, it may have some rest of sea salt or sand that i removed by cleaning it.
Let me know if you are lucky.

MC
mcappel
 
Posts: 4
Joined: Sun Jun 19, 2011 5:40 pm

Re: GoPro brick revival?

Postby Kilrah » Tue Nov 08, 2011 6:42 pm

Hi,

Thanks for the suggestion, no luck though :(
Kilrah
 
Posts: 25
Joined: Mon Sep 19, 2011 9:01 pm

Re: GoPro brick revival?

Postby Greg_E » Fri Nov 11, 2011 7:11 am

I think you need to look at the discussion of the JTAG interface, this should let you push a firmware to the processor but I can't really help with the specifics. You will also need a firmware image extracted from a camera, I don't think you can just push the file to the processor but I might be wrong.
http://transportcontrols.com
Updated with version 1.
User avatar
Greg_E
 
Posts: 1646
Joined: Thu Jan 28, 2010 7:39 am

Re: GoPro brick revival?

Postby Kilrah » Thu Nov 24, 2011 11:38 pm

Yeah, JTAG requires addresses and programming methods we have no idea of in the GoPro's case...

Anyway, I've got a GoPro 2 now, so nevermind :D
Kilrah
 
Posts: 25
Joined: Mon Sep 19, 2011 9:01 pm


Return to GoPro Interface BUS

Who is online

Users browsing this forum: No registered users and 0 guests

suspicion-preferred