Was that before or after you took it apart?
Haha I never took apart an alp cpu haha. Have ripped apart G9 ones though haha.
They are easy to glitch and gain access to their os.
Sent from my GT-I9505 using Tapatalk
A protected boot loader, checksumming the file, and verifying after write would prevent the majority of "bricked" CPUs due to a bad flash.
Even better is if the CPU contained two banks/blocks of program memory, and each firmware update is written to the alternate bank, verified, then the vectors re-assigned. A failed update would simply revert back to the previous version still intact in the other bank. I don't know how easy this is to do on PIC24 devices, but if the code is written to be relocatable, or jump addresses are adjusted during the flashing process, it should be doable as long as the CPU has at least 2x the program memory needed to store the firmware.
Asset protection can be provided through encryption of the file (and decrypted by the boot loader during the flash), and using the PIC's built in program memory protection features.
I wonder, if one has a bricked CPU if it could be resurrected using a valid firmware file and a PIC programming tool.
Makes sense , a lot .
I am far from being an expert , but my thinking is as follows : when a cpu is bricked what is
broken exactely : is it the ''brain'' that refuses to listen\read the instructions or it is
the hardware that cut communication .
If i was designer of such : i would have a secret backdoor that could only be open
with a dedicated code \ so as to open the comm between the hardware & the firmware \
This code would only be supplied thru email after proper identification by the seller.
As my dash experience : the manufacturer Qrontech sent me a debugging file
that i wrote on the sd and put in the cam ...it was supposed to fix it ...but
nothing happened . I supposed the system locked him-self and nothing would make
him listen ....
Those things are almost human:frusty:...
Typically if a firmware update "bricks" the cpu the operating system/bootloadser code is corrupted so it no longer functions, since the programming that makes it work is gone/corrupted. Think of when the HDD dies in your PC and it no longer boots, it's sort of like that, though more like if you hose your computer's BIOS so it doesn't even POST.
Once it's bricked it no longer has the code needed to read the new firmware off the thumb drive. The only fix is to reflash the chip directly using a chip programmer. A write-protected bootloader that contains the firmware update functionality would prevent most "bricking" from occurring, since then if an update fails you can simply try it again.
So, to answer your question, the hardware is still there but it has no working software to run.
My unit worked fine for my trip after the 1/29 firmware. When it went to boot up the second time it was dead. I use a sandisk drive. A replacement was sent to me the Saturday that I reported it and received the new one Monday. ALP sent a firmware file to me and it loaded fine. I haven't had a chance to try it with all the snow we had in NY. They said it my be that I had the str+ upgrade.
This is good to be aware of BRD, Thx, fix the problem before it occurs
That's probably true, but it would be nice if they could provide a bootloader-only .hex file for unbricking a CPU, after which you'd load the real firmware via a thumb drive. At least make it available to dealers like BRD so they can fix bricked CPUs without having to send them back to Antilaser.