LK-7900 ARA likely bricked, any options?

BenFenner

New Member
Joined
Oct 28, 2020
Messages
13
Reaction score
5
Location
Columbia, SC
Country
United States
I've had an LK-7900 ACE for over 7 years. The 7-segment display died a long time ago, and then the internal battery finally died, prompting me to think about replacement.
I learned the LK-7900 ARA came with an internal capacitor instead of the battery, so I just went with that for ease of upgrading. I purchased it about 18 months ago, but I haven't gotten around to working with it until just now.

It was either DOA, or possibly bricked after attempting a firmware update. Regardless, it doesn't work right now. When I power it up, the front-facing blue light blinks once or twice, and then I don't get anything displaying on the rear display, nor any voice announcements.

There are a few excellent threads about recovering the LK-7900 ACE while in this state. This might be the most comprehensive: https://dashcamtalk.com/forum/threads/lk-7900-ac25-ac27-update-turned-camera-into-brick.2590

I'm hoping for some advice from the forum. Is there anything I should try next? Would contacting Lukas/Qrontech be useful? How would I go about doing that?

Do we think the ARA is similar enough to the ACE that the unbrick technique(s) found elsewhere in this forum subsection would be worth trying? (I don't have easy access to a Linux machine right now, if that matters.)

Should I give up and just disassemble my ACE unit and replace its battery? (I tried once, but could not get into the main body. I see instructions on the forum now though, so I could give it another shot.)
 
Last edited:
Well, I guess I'm being a bit impatient, since I've given a few more things a try. I'd almost rather just be finished with the project one way or another, versus spending a lot of time and effort on it. (I have so many other things I'd rather be doing right now.)

In a last-ditch effort to get the thing to do something, I tried loading the unbrick AC23 firmware meant for the ACE unit that has worked to unbrick many of those units.
By some luck, it actually worked on the ARA unit as well. Well, I'm sure it has some pretty mismatched firmware on there now, but the rear segment display actually works now! This is a first.
It reads "Ac23" which is obviously the firmware version, but then never continues on to say anything else. I was expecting it to eventually say "SD_Fail" or something...

This is very promising though. I wonder if I can update to the correct firmware from here, or possibly get the unit working in a reduced functionality mode (as an ACE instead of an ARA) or maybe it is worth DIY-ing my own unbrick boot loader with the proper firmware using Craig's technique in the thread linked above.

I'll see how things go.
 
Well, I dusted off a copy of Ubuntu 12.04.2 LTS (32-bit) on CD and loaded a live preview on my laptop.
I ran the "make" command to give the DIY firmware boot loader SD card a try.
The make command completed successfully from what I could tell, giving me two new executables "FirmwareSplitter" and "CreateSDBoot" placed on the SD card I'm using for all of this.
However actually trying to run FirmwareSplitter doesn't seem to work. I'm getting denied permission, and "sudo" doesn't seem to be recognized as a command.

I will look into this and see what I can do. I'm hoping it is some old Ubuntu oddity I can research.

Edit: It seems clear that things are not working because the FirmwareSplitter file is not marked as executable. I've tried remounting the SD card as executable, and adjusting the permissions on the file, but none of that is working. I'm still researching how to fix this.

Edit: For whatever reason I could not get the executable flags sorted, so I copied everything to the /home directory, and was able to set the executable flags properly there. Now that I'm able to run FirmwareSplitter, I've got my next problem. I don't actually know what the files are called inside the A37 firmware file I'm working with. FirmwareSplitter needs the correct names of the files. I'll see what I can do.
 
Last edited:
You are better off getting something new, sensors alone have come a long way since those days, and besides Lukas image quality have always been lackluster with very aggressive sharpness / contrast and extremely moderate bitrates.
Just when i upgraded from my LK-7500 to something better, it took a while to get used to the then softer image after looking at lukas footage for a while, and it is a much better ballgame today, where as likan seem stuck in a rut.
 
Well, I've tried using the "Standard" and "OBD" firmwares for the ARA unit. Sadly, I can't seem to guess the correct file names contained within the firmware to extract them with the FirmwareSplitter tool.

The "Ident" in the header of each firmware file is "Lc37" and "OA37" respectively, but prefacing each of the files needed as shown below does not work. I'm told the files do not exist.

./FirmwareSplitter firmware Lc37_Ident.bin Lc37_UBLNand.bin Lc37_UBoot.bin Lc37_Kernel.bin Lc37_RootFS.bin
./FirmwareSplitter firmware OA37_Ident.bin OA37_UBLNand.bin OA37_UBoot.bin OA37_Kernel.bin OA37_RootFS.bin

Unless I can somehow figure out the names of the files inside the firmware binaries, I'm not sure I'll be able to carry forward. :(
 
I agree kamkar it is probably best to just move on. I will accept that fate if I can't get this unit working. I am not looking forward to running another set of wires through my car (the aged headliner material on the A-pillar took a beating last time) but I'll cross that bridge when I have to. That is one of the main reasons I stuck with the same form factor of camera when replacing my old one. =/
 
A fun tid-bit of info about the ACE versus ARA units. The Lukas web site shows the same firmware (AC37) for both units, assuming the ARA is not an OBD unit (which mine is not).
So that's promising. I still can't get that firmware to turn into a boot-able SD card image using Craig's tools, but maybe I could get AC31 working. If I could just find that somewhere to download. I've been looking all over, with no luck.

If you're following along, I've also tried the file prefaces below, with now luck:

./FirmwareSplitter firmware AC37_Ident.bin AC37_UBLNand.bin AC37_UBoot.bin AC37_Kernel.bin AC37_RootFS.bin
 
Hi Ben,
It's been quite some time since I last had to use those tools. I'd need to re-familiarise myself with making a bootable sd card.
As it happens, I'm still using the same (ACE I think) dash cam, though it's on its last legs.
Last year it went through the symptoms you have described. The display had lost a few segments. Then suddenly one day it let out the magic smoke.
Quite strange really, i got into my car and couldn't understand what I was seeing. A whisp of smoke had drifted in front of my face, and it took a while to realise what I was looking at. The cam stopped working.

After disassembling the cam, I discovered the electrolytic super capacitors had leaked electrolyte into the pcb. It has caused a short between a via and the ground plane. I scraped off the surface copper, and started to dig down through the pcb layers. The FR4 had carbonised, and was causing numerous short circuits between the power supplies and the ground plane. I ended up digging out a fair amount of black carbon, and destroying several internal pcb traces along the way. It has caused some of the led display segments to burn out due to overcurrent.
The electrolyte was cleaned from the pcb using mek. This also explained the behaviour that the cam had, for at least a year, stopped saying "terminating the system" when the power was switched off. I suspected the super caps were knackered for some time, but I didn't think for a moment they had started to leak.

Anyway, after digging out the carbon (see dark spot on attached photo), and cleaning up the board, the cam would boot up ok. There was an error code on booting, which suggested that the internal clock had lost its time. The display had also completely stopped working I reinstalled it into the car and forgot about it for a few days.
Somehow I became aware that the GPS had also stopped working. After opening it up again, I discovered that the GPS is a self contained module in the foot of the cam, with power and serial port connections routed to it via a pcb header. I determined which pins must be the data, and found that no voltage was present at the header power pins. It was obvious that the pcb traces I had obliterated in clearing the carbonisation must have been supplying power to the GPS. At this point, I made a guess that the GPS required a 5V supply, and fitted a link wire from the GPS header to one of the 5V rail smoothing caps.
This fixed the GPS problems, and also caused the rear display to spring to life, albeit with a few segments missing.
The super caps were later replaced so that the cam can cleanly shut down when the power is lost. Since the replacements were physically larger than the originals, they are now external to the cam, with wires leading inside.

So the lesson to learn from all of this is that's I should have investigated the various malfunctions before the fault developed. I could have quite easily removed the super caps after they started to leak, and saved a lot of hassle.

You might be wondering why I had gone to all this trouble to repair such an old dash cam. The reason is that the cam is now heavily customised, with modifications and external modules in the vehicle. The event switch input can be activated from an external microcontroller which receives inputs from microwave sensor, additionally the microphone is now external.

As for the firmware tools, I don't believe the filenames are used for anything other than to specify the names of the files. I'd need to take another look to refresh myself, but I don't believe the name would have any relevance to what is inside the firmware image.

Regards
Craig
 

Attachments

  • 20190618_180653.jpg
    20190618_180653.jpg
    325.1 KB · Views: 2
Craig, thank you so much for your reply. If anyone is worth talking to about this, it seems to be you. ;)

I'm sorry to hear about your troubles, but you've obviously got the situation under control.

As for me, I looked through the C code of your Firmware splitter and thought the file names mattered to somehow target inside the firmware binary, but I could be reading the code wrong. I'm not up on my C like I should be.

I have a branch down (wind) on the main power line to my house right now. When that gets sorted out, I'll load up the Ubuntu Live CD again and get you exact error messages. From memory, I believe they were:

ERROR: Unable to open AC37_UBLNand.bin
ERROR: Unable to open AC37_Kernel.bin
ERROR: Unable to open AC37_Ident.bin

And presumably it's looking for those 3 files because the header describes size for those 3, but not the other 2 file names in the command? Again, I'll get the real output in a bit.

I'm not sure how much you want to futz with this, as I know it's been a long time since you hacked on this, and I'm just a random person with a bricked cam. =/
 
Hi Ben,

Hope you get your power back on. I'm fortunate to be off-grid at the moment, though the solar isn't doing too well at this time of year.

I've had a bit of a refresh on the Lukas firmware tools, and can confirm that i've been able to download the firmware for the LK-7900 ARA and generate a bootable SD card for it. There one one subtle deviation from the instructions provided in the Readme.txt

The file I Downloaded was:
77f6a3e2c672bc54e1f7d540de938304c001773dc532e1854a6476b3e942c6a2 LK-7900_OBD_FIRMWARE_OA37.zip

The zip file contained the following files:
9c7acf107555ca2a8fc7dbf5360229ab06728d29561cf39a643920e6d5711e09 firmup 73f544efbd559689068aa2f6aa8ed11dc79db792151b6c7e9fee4a068c3e7354 lk79obdf c0a317f60910eed08bbfc7b3ac6e6de1b2029bf4922d0b0d7d3759313a24b16c updatef.txt

Note that in the zip file for the LK7900 ACE, the firmware was contained in a file called "firmware".
You will need to modify the command line slightly because in this zip file the firmware is contained in a file called "lk79obdf".

With the firmware zip file extracted into the same directory as the FirmwareTools executables, I ran the command:

./FirmwareSplitter lk79obdf OA37_Ident.bin OA37_UBLNand.bin OA37_UBoot.bin OA37_Kernel.bin OA37_RootFS.bin

Which generated the following output in the terminal:

Magic: 0x16161616 Ident: OA37 Mystery Number: 0x00000101 UBL Size: 0x00005000 UBoot Size: 0x00049f0c Kernel Size: 0x00000000 RootFS Size: 0x00000000 Total File Size: 0x0004ef30 CRC: 0xa07c85f4

I then ran the command:
./FirmwareSplitter firmup OA37_Ident.bin OA37_UBLNand.bin OA37_UBoot.bin OA37_Kernel.bin OA37_RootFS.bin

Which generated the following output in the terminal:
Magic: 0x16161616 Ident: OA37 Mystery Number: 0x01010000 UBL Size: 0x00000000 UBoot Size: 0x00000000 Kernel Size: 0x001567fc RootFS Size: 0x03760000 Total File Size: 0x038b6820 CRC: 0x7e34bbeb

The above two commands produced 5 files. The checksums can be calculated with the following command:
sha256sum OA37_*

This generates the output:
9a4086b46e79921fb688241375ad70239ce62e543241363b916a55e3a13381c1 OA37_Ident.bin ebb42f0840514291a2f9a33ad2231a370330e52280b23a262e71ce8232c8916a OA37_Kernel.bin ef69e05d202daf9d0008552e09590b4b436b2990e01e845a44a3998d5a6495f3 OA37_RootFS.bin 75614d20ec780cfd60f41505428ad82edb3203884326e4acaf8a4c91987cb967 OA37_UBLNand.bin 32f73926f51e8898c448bf01cdea1f0bae646352899e0abbe0bd8f0eabfe30b3 OA37_UBoot.bin

At this point we have all of the ingredients to make a bootable SD card using the command:
./CreateSDBoot AC23_UBLSDBoot_MOD20140119.bin AC23_TestPatterns.bin OA37_UBLNand.bin OA37_UBoot.bin Environment.bin OA37_Ident.bin OA37_Kernel.bin OA37_RootFS.bin OA37_SDCard.img

The above command generates no text output if it's successful.

It created OA37_SDCard.img.
d1487f596b24686a20e6b36be9b3c3eac32132d2007af0fdd6a4f4da9a5d5bf1 OA37_SDCard.img

This needs to be written to an SD card using the DD command, targetting the raw device node.
Before doing this in ubuntu (which will probably need to be done as root), make sure the filesystem of the card is not mounted, and be sure to choose the correct device node in /dev.
Just as a warning, in /dev there will also be device nodes for your hard disk and system firmware/BIOS. Don't write to the wrong one!

Hope it works!

Regards,
Craig
 
Craig, thank you so much for the effort.

I am aware of the file name change for the OA37 firmware, and was able to deal with that appropriately. I still was getting error messages about missing files.

I'll give it another try. Technically I was mostly trying with the A37 (strangly with an internal header Ident of Lc37) firmware (for non-OBD LK-7900 ARA units) but I did try with the OA37 firmware (for OBD ARA units) as well, taking care to use the new file name as you did. I still got the errors.

I will be dealing with this fallen limb (and learned my car took damage in the garage too) for the foreseeable future, but when I get a chance I will give it another try.

(I will be avoiding dd and using Win32 Disk Imager on Windows 7 to write the image to an SD card. It worked perfectly for the AC23 unbrick utility.)

I wonder, if you're able to make the bootable images with no issues, maybe you'd host two of them here? One for each of the lastest ARA firmwares (OBD and non-OBD)? Sorry if that's too much to ask... I know you'd prefer I learn how to fish. :)
 
Thank you Craig for providing the two bootable images.

I was able to apply AC37 to the device. Well, that's what the read-out says now ("Ac37"). However it never emits any sounds, and it never reads "SD_Fail", and it doesn't seem like it is actually doing anything. I tried putting in another card setup to record, and I got nothing.

When I do the OA37 update, the device never displays anything on the read-out. So I'm doubtful that is applying properly. I wonder if this is how the device came to me...

I applied AC37 again and I'm back to seeing "Ac37" on the rear read-out, but nothing further.

I'm wondering what is next. I almost wonder if my bench setup isn't sufficient. I have a 12v (tests at 15v or so) power supply good for 1,500 mA. I hope that is enough amperage...

At this point I wouldn't mind donating it to you Craig if you thought you'd have a use for it. =/
 
Thank you Craig for the new batch of images. This time hopefully with all ~58MB of the firmware.

I've made two observations.

1) The original bootable unbrick image (AC23) will mount to Windows and show 2 files existing on the main partition. But at nearly 4GB, I'm sure something is up with it...
None of the images I've worked with otherwise exibit this behavior. None of them will mount in Windows. Just an observation.

2) After booting to the SD card using the dash cam, and loading some firmware via unbrick images, I've never had the device tell me to format the card when finished. I've never had it give any indication that it has finished. I've been giving it 5-10 minutes to flash each time, but as far as I can tell, none of them have ever "finished" properly. Even the original unbrick AC23 image. Again, just an observation.

Edit: I'm sorry to report I seem to be getting the exact same behavior as last time. The AC37 image causes the device to display "Ac37" indefinitely, and the OA37 image causes no display.
 
Last edited:
On a whim, I loaded the original 4GB AC23 image again. I left it for ~15 minutes to load, or a bit longer than normal.

I'm seeing "Ac23" on the back, and now it is scrolling "Sd_FAIL" as well.
Oh, and it's also showing what looks like the time (4:13) sometimes.
No audio voice coming from the unit, but it's behaving better than it ever has before.

I may try putting in a different SD card with an ACE-style config file to see if I get anything recording.

Edit: That worked! I got voice "Welcome to Black Box. Recording started." I have the time, or similar displaying... I assume it is recording. I will check.
Turning it off I heard "Terminating the system" and saw "See you" on the display. All as normal.
Yep, I got some video files on the SD with audio. :)

This is obviously not ideal, as I'm using old ACE-style firmware right now on an ARA unit. But this is a nice "home base" to start from at least.



Maybe a normal firmware update would work from here...
It seems I have a few things I can try from here. :)
 
Last edited:
Strange. Either it's taking an enormous amount of time to write to the internal memory, or its taking a long time to boot up after the firmware has been written.

As for the question regarding three structure of the SD card, I wouldn't expect to see any files on the card when generated using my method.

It would be useful to connect a serial cable to see if any warning messages are being reported, as there could be a hardware problem.

It might be worth booting ac37 sdcard, and just leaving it for a long time to see what happens. You might need to leave it several times longer than AC23 due to the file size difference.

BTW, the boot loader contains code to display the firmware version before it boots Linux, so there could be any number of possible issues which result in only the firmware version being displayed.
 
With the original unbrick firmware of AC23 on there working well, I was then able to follow the normal firmware update process to get AC37 on the device!

(After first trying to format the SD card inside the device, which I think either severly limited the partition size, or it happened after many rounds of writing images. I had to download a better partition utility than Windows Disk Manager to get all of the 16GB of card space back. Once that was done, I was able to "format" it using the ARA player, then put the AC37 firmware on the card.)


Things are working great now. Everything is as expected! I get all the right audio, displays, behavior, recording, etc.!
I'm sorry Craig that so far it seems I was not able to get your bootable firmware updates working. I know you're curious to see how those would go, but the result I have now is more of what I'm after. I can't say I want to keep trying if the device is working. =/

I think the last thing I need to do is change from KPH to MPH (which I thought I already had).

I'm quite surprised I'm here now with a working device. Let me keep fiddling with it and report back.
 
Last edited:
The best I can tell, this thing is working perfectly now. As long as it is trouble-free for the next 5+ years (like the last one) I hope to basically forget all about it.

I'm very grateful to you Craig for coming out of retirement and helping me with this. Even though your tool may not have explicitly solved the problem, the simple fact that it existed kept me hopeful and motivated to try many things (even the same things repeatedly) which eventually got me a working unit. If it weren't for you then, and now, I wouldn't have tried nearly as hard.

I hope maybe someone else in a similar situation get even half the help you gave me.

Cheers, and thanks again!
 
You're welcome. Glad to hear you got it working and that a bit of perseverance has paid off in the end. These Lukas cameras do seem to be "fit and forget", so hopefully just a case of feeding it a new SD card every now and then.
Also, hope you got your fallen tree sorted.
All the best
--
Craig
 
Back
Top