Should I have received my final order eMail already?


Don't want to keep on posting here about not receiving an email here as I don't want to spam up this thread too much but I checked again and included the spam directory but nope no email so far.

ljones
 
Don't want to keep on posting here about not receiving an email here as I don't want to spam up this thread too much but I checked again and included the spam directory but nope no email so far.

ljones
I managed to get mine sorted out using a private message to ED. At the time in early Feb it only took him 6 days to reply, although that can vary.
 
Hey guys! Did you miss me? I finally have an update on my Pyra, which didn't want to charge likely due to hardware issues.
It was tough process due to COVID limitations and delivery to Mother Russia particularities, but Michael yet again proved to be a great guy - he solved everything despite the apparent lack of time.
As the result I swapped the motherboard and now it charges normally (bearing in mind the current software limitations).
Nevertheless the second issue is still present - it doesn't like to boot straight after shutting down. When I press power button keyboard backlight blinks for a millisecond, then a green logo light comes on and nothing happens. It can sit is this state forever. Nevertheless if I let it rest for 20-30 min it will boot up normally.
I raised this question previously here when I first encountered this issue, but general suggestion was to reflash. Well, I did it then. And repeated now, with different images, SD cards and even with a boot SD card. Nothing changes.
As a possibly important note - it didn't do this when it just arrived. It didn't charge, but booted OK. The issue appeared first when I reflashed it back then trying to figure out the charging issue. And since then it is present, even with a new motherboard.
ED told me that this could be related to u-boot that some CPU boards are picky about, and that a new u-boot is around the corner. We will see, if it manages to solve the issue.
 
Hey guys! Did you miss me? I finally have an update on my Pyra, which didn't want to charge likely due to hardware issues.
It was tough process due to COVID limitations and delivery to Mother Russia particularities, but Michael yet again proved to be a great guy - he solved everything despite the apparent lack of time.
As the result I swapped the motherboard and now it charges normally (bearing in mind the current software limitations).
Nevertheless the second issue is still present - it doesn't like to boot straight after shutting down. When I press power button keyboard backlight blinks for a millisecond, then a green logo light comes on and nothing happens. It can sit is this state forever. Nevertheless if I let it rest for 20-30 min it will boot up normally.
I raised this question previously here when I first encountered this issue, but general suggestion was to reflash. Well, I did it then. And repeated now, with different images, SD cards and even with a boot SD card. Nothing changes.
As a possibly important note - it didn't do this when it just arrived. It didn't charge, but booted OK. The issue appeared first when I reflashed it back then trying to figure out the charging issue. And since then it is present, even with a new motherboard.
ED told me that this could be related to u-boot that some CPU boards are picky about, and that a new u-boot is around the corner. We will see, if it manages to solve the issue.
Seems likely to be heat related to me, if letting it cool down allows it to boot. Alternatively there could be some capacitor or something that needs to discharge before booting will succeed, but I can't see why anyone would engineer that into a handheld.
 
Seems likely to be heat related to me, if letting it cool down allows it to boot. Alternatively there could be some capacitor or something that needs to discharge before booting will succeed, but I can't see why anyone would engineer that into a handheld.
I have the same opinion basing on my observations. I thought motherboard replacement would solve this. Nevertheless, it didn't. I was also surprised by the information from ED that it is most likely software related.
 
Seems likely to be heat related to me, if letting it cool down allows it to boot. Alternatively there could be some capacitor or something that needs to discharge before booting will succeed, but I can't see why anyone would engineer that into a handheld.
It's not heat related - it's the memory initialization.
Sometimes the memory shows two corrupted bytes in U-Boot and therefore doesn't boot.
On some boards it happens never, sometimes one out of 50 boots and with some it happens regularly.
By tweaking some settings, we managed to get it working with almost any CPU board right away.
But I noticed we're flashing a different U-Boot version that has different memory tweaks and isn't as reliable here.

We don't know where exactly the issue comes from. We suspected noise and bad hardware traces - but you can do an eyepattern check and that looks perfectly fine even on the boards that won't boot.

Additionally, once the boards boot, they work perfectly fine - so there aren't memory errors after the initialization, so the issue has to be hidden somewhere in the initialization routines.

Some of the U-Boots we built restart when an error happens until it fully boots. So if he used one of these U-Boots and let it sit for a while, it will eventually boot.

Not because of the heat - but because the memory error didn't happen.

It seems it's some timing / tolerance issue.
 
It's not heat related - it's the memory initialization.
Sometimes the memory shows two corrupted bytes in U-Boot and therefore doesn't boot.
On some boards it happens never, sometimes one out of 50 boots and with some it happens regularly.
By tweaking some settings, we managed to get it working with almost any CPU board right away.
But I noticed we're flashing a different U-Boot version that has different memory tweaks and isn't as reliable here.

We don't know where exactly the issue comes from. We suspected noise and bad hardware traces - but you can do an eyepattern check and that looks perfectly fine even on the boards that won't boot.

Additionally, once the boards boot, they work perfectly fine - so there aren't memory errors after the initialization, so the issue has to be hidden somewhere in the initialization routines.

Some of the U-Boots we built restart when an error happens until it fully boots. So if he used one of these U-Boots and let it sit for a while, it will eventually boot.

Not because of the heat - but because the memory error didn't happen.

It seems it's some timing / tolerance issue.
That all sounds pretty logic, but I still do not get one thing - why a 20 min rest in off state allows it boot? And why is it guaranteed not to boot immediately after it was switched off or removed from long charging cycle (in both cases device is warm)? This pattern is too evident to ignore.
 
Well, I don't know what exactly you did test, but were you sure the Pyra was switched off completely?
If the green light on the logo is on, the CPU is active and you can't start the Pyra in that case.

When you try to reboot, it crashes - so it's in an On-State and can't be booted either.
 
Well, I don't know what exactly you did test, but were you sure the Pyra was switched off completely?
If the green light on the logo is on, the CPU is active and you can't start the Pyra in that case.

When you try to reboot, it crashes - so it's in an On-State and can't be booted either.
Step by step: 1) Playing some GBA, surfing boards etc; 2) Turn it off in a normal way; 3) Push the on button - keyboard blink, green logo on, nothing happens; 4) 10 seconds power button hold or battery pull to power it off (green logo goes off); 5) Repeat steps 3 and 4 dozen of times with no positive result; 6) Let unit sit in off state for 20 min or so (in multiple configurations, like with battery, without battery, with an improvised battery that always tells that it is cold); 7) Push power button and boot successfully (if it does not work let the unit sit in off state for 5-10 min more).

I repeated this a lot of times with old and new motherboard (same CPU board). Result is always the same. The only test left I have in mind - measure exact time unit shall sit in off state before it will boot and check whether putting it in a fridge will affect this time
 
Last edited:
Seems likely to be heat related to me, if letting it cool down allows it to boot.
Congrats - we were right.

It's not heat related - it's the memory initialization.
I´ve finally done the fridge test. After being left if the fridge to cool down to 6 C Pyra was able to perform OFF - ON - OFF cycle for 6 times in a row, while even 2 such cycles are not possible at a room temperature. After that it was failing too boot and cooldown for a successful boot was getting longer each time (as the device was getting warmer). I can also state that it is not a battery failure, as an improvised battery with 10kOhm resistor didn´t improve anything previously.

Any ideas? I would blame CPU temperature sensors and/or algorithms.
 
Congrats - we were right.


I´ve finally done the fridge test. After being left if the fridge to cool down to 6 C Pyra was able to perform OFF - ON - OFF cycle for 6 times in a row, while even 2 such cycles are not possible at a room temperature. After that it was failing too boot and cooldown for a successful boot was getting longer each time (as the device was getting warmer). I can also state that it is not a battery failure, as an improvised battery with 10kOhm resistor didn´t improve anything previously.

Any ideas? I would blame CPU temperature sensors and/or algorithms.
It may be both, Memory Initialization issue may clear up with the Pyra being cooler. the colder temp may be enough shift a race condition in the initialization sequence or something along those lines. The end all fix likely could be adjusting the timing like Evildragon states, just the temp of the Pyra is a factor in your current situation.
 
It may be both, Memory Initialization issue may clear up with the Pyra being cooler. the colder temp may be enough shift a race condition in the initialization sequence or something along those lines.
I agree, but do not believe it is highly probable that a temperature shift of around 40 degrees C could cause enough copper expansion to change the traces characteristics. Thermal resistance shift should be even more negligible.

ED mentioned that he has some CPU boards showing similar boot issues. I wonder if he could perform the same fridge test. We might be up to something important.
 
Back
Top