Close
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21
  1. #11
    Senior Member BestRadarDetectors's Avatar
    Join Date
    Oct 2013
    Location
    NJ
    Posts
    4,503
    Thanks Given
    472
    Thanked 5,550 Times in 2,134 Posts
    Quote Originally Posted by beingaware View Post
    I've also had a toasted CPU but mine had a DOA port lol.
    Was that before or after you took it apart?
    Need Help Choosing a Radar Detector for your needs? Visit our website: http://www.bestradardetectors.net, Send us a PM or call us at 1-888-229-7594
    Before looking at an Escort Radar Detector you should really check out Uniden Detectors.. Uniden R1 & R3 are the best performing radar detectors for the money.

  2. #12
    Senior Member beingaware's Avatar
    Join Date
    Nov 2013
    Location
    FIFO
    Posts
    2,125
    Thanks Given
    1,514
    Thanked 2,070 Times in 973 Posts
    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
    Last edited by beingaware; 02-05-2014 at 05:31 PM.
    Defence: ALP x 3 Front / 2 x Angled Rears | Stinger VIP Radar x 2 Patch Panels / Stinger VIP LIDAR (testing)| Escort Redline 2013 int | Escort Redline MRCT 2015 int | STI-R+ | V1 (testing) | Veil
    CM Testing: Spectre RDD Mrk IV | UltraLyte LR UX 125pps | UltraLyte LRB 125pps | Stalker LZ1 | ProLaser 2 (The Hole Finder) | Kustom Talon 2 KA | Bushnell Velocity K Band
    Intelligence: Front/Rear Dash Cam | 477MHz 2-WAY Radio
    Want your jammer setup tested? Want to confirm your RD is stealth? Send me a PM.
    <a href=http://www.raletc.com target=_blank rel=nofollow>http://www.raletc.com</a>

  3. #13
    Senior Member radargeek's Avatar
    Join Date
    Jan 2014
    Location
    York, SC
    Posts
    525
    Thanks Given
    116
    Thanked 571 Times in 270 Posts
    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.
    If I passed you on the right, YOU are in the wrong lane!

    2016 Encounters/Saves (to date): 33.8: 1/1 (last 4/13) | 34.7: 1/1 (last 3/11) | 35.5: 19/11 (last 8/28) | K: 1/1 (last 6/26)
    2015 Encounters/Saves: 33.8: 1/0 | 34.7: 13/4 | 35.5: 19/10 | K: 4/1 | LIDAR (sighted/hit with/save): 4/1/1

    ACTIVE CMs: Redline X, K, Ka 2,4,5,8 (highway/long trip RD) | New! V1C 3.8945 K, Ka CS, TMF2 w/YaV1 (in-town RD) | ALP Quad | BlackVue DR650GW-2CH

  4. The Following 2 Users Say Thank You to radargeek For This Useful Post:

    beingaware (02-05-2014), Tman (02-05-2014)

  5. #14
    Senior Member Tman's Avatar
    Join Date
    Nov 2013
    Posts
    1,143
    Thanks Given
    1,485
    Thanked 783 Times in 373 Posts
    Quote Originally Posted by radargeek View Post
    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...

  6. #15
    Administrator Mirage's Avatar
    Join Date
    Oct 2013
    Posts
    1,146
    Thanks Given
    539
    Thanked 1,644 Times in 520 Posts
    Quote Originally Posted by beingaware View Post
    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
    Haha he said glitch I wonder how many know about that! Havent heard that in years.

    MirageTools.net
    - Laser CM Reviews and Tools
    RALETC.com - Radar and Laser Expert Testing Cooperative
    AL PRIORITY (Quint) w/BT, RG, & STiR | V1 3.892 + YAV1 | BlackVue DR650GW-2CH

  7. #16
    Senior Member radargeek's Avatar
    Join Date
    Jan 2014
    Location
    York, SC
    Posts
    525
    Thanks Given
    116
    Thanked 571 Times in 270 Posts
    Quote Originally Posted by Tman View Post
    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 .
    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.
    If I passed you on the right, YOU are in the wrong lane!

    2016 Encounters/Saves (to date): 33.8: 1/1 (last 4/13) | 34.7: 1/1 (last 3/11) | 35.5: 19/11 (last 8/28) | K: 1/1 (last 6/26)
    2015 Encounters/Saves: 33.8: 1/0 | 34.7: 13/4 | 35.5: 19/10 | K: 4/1 | LIDAR (sighted/hit with/save): 4/1/1

    ACTIVE CMs: Redline X, K, Ka 2,4,5,8 (highway/long trip RD) | New! V1C 3.8945 K, Ka CS, TMF2 w/YaV1 (in-town RD) | ALP Quad | BlackVue DR650GW-2CH

  8. The Following 3 Users Say Thank You to radargeek For This Useful Post:

    curmudgeon (02-08-2014), RedRocket (02-08-2014), Tman (02-05-2014)

  9. #17
    Member
    Join Date
    Nov 2013
    Location
    LI, NY
    Posts
    54
    Thanks Given
    0
    Thanked 29 Times in 10 Posts
    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.

  10. #18
    Junior Member
    Join Date
    Jan 2014
    Posts
    2
    Thanks Given
    0
    Thanked 1 Time in 1 Post
    Quote Originally Posted by Tman View Post
    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...
    I'm 99.99% sure that the "bricked" CPUs can easily be repaired with any ICSP tool (pic programmer). I highly doubt that ALP would release a .hex file for you to use though, so it'd probably have to be sent back.

  11. The Following User Says Thank You to mb300sd For This Useful Post:

    RedRocket (02-08-2014)

  12. #19
    Junior Member assailant's Avatar
    Join Date
    Feb 2014
    Posts
    20
    Thanks Given
    1
    Thanked 2 Times in 2 Posts
    This is good to be aware of BRD, Thx, fix the problem before it occurs

  13. #20
    Senior Member radargeek's Avatar
    Join Date
    Jan 2014
    Location
    York, SC
    Posts
    525
    Thanks Given
    116
    Thanked 571 Times in 270 Posts
    Quote Originally Posted by mb300sd View Post
    I'm 99.99% sure that the "bricked" CPUs can easily be repaired with any ICSP tool (pic programmer). I highly doubt that ALP would release a .hex file for you to use though, so it'd probably have to be sent back.
    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.
    If I passed you on the right, YOU are in the wrong lane!

    2016 Encounters/Saves (to date): 33.8: 1/1 (last 4/13) | 34.7: 1/1 (last 3/11) | 35.5: 19/11 (last 8/28) | K: 1/1 (last 6/26)
    2015 Encounters/Saves: 33.8: 1/0 | 34.7: 13/4 | 35.5: 19/10 | K: 4/1 | LIDAR (sighted/hit with/save): 4/1/1

    ACTIVE CMs: Redline X, K, Ka 2,4,5,8 (highway/long trip RD) | New! V1C 3.8945 K, Ka CS, TMF2 w/YaV1 (in-town RD) | ALP Quad | BlackVue DR650GW-2CH

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •