From 3757e0f3bf3336d26ce8c4e3abd17f0d63736283 Mon Sep 17 00:00:00 2001 From: Brumi-2021 <86470699+Brumi-2021@users.noreply.github.com> Date: Fri, 14 Jul 2023 18:25:52 +0200 Subject: [PATCH] Updated Won't boot (markdown) --- Won't-boot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Won't-boot.md b/Won't-boot.md index 10ed041..cab983d 100644 --- a/Won't-boot.md +++ b/Won't-boot.md @@ -88,4 +88,4 @@ Then , Firmware starting at version 1.5.4 and onward contain the Pull Request 662 that uses the persistent memory to test and store the hardware and LCD config settings . That memory uses the same back up voltage than the Real Time Clock calendar, both needs a healthy cell battery button voltage. Sometimes, in a re flashing process , although we got good battery cell button voltage, the unit seems to be badly initializing those persistent bytes and we got strange black screen. Doing those above steps probably reset the persistent memory. That's just a guess. ### Additional notes : -I used to have many frequent “black LCD boot brick” when exchanging binaries compiled with different gcc-arm… version , from 9.4 to 10.3 or 12 . But thanks to @u–foka‘s PR fix pmem -> make backup_ram_t data members volatile #1135, all those problems are gone , and now I do not have any persistent memory boot problems , so I do not need to go back to any old version 1.4.3 anymore. +I used to have many frequent “black LCD boot brick” when exchanging binaries compiled with different gcc-arm… version , from 9.4 to 10.3 or 12 . But thanks to @u–foka‘s PR fix pmem -> make backup_ram_t data members volatile [#1135](https://github.com/eried/portapack-mayhem/pull/1135), all those problems are gone , and now I do not have any persistent memory boot problems , so I do not need to go back to any old version 1.4.3 anymore.