Last week, the shoulder buttons arrived at my place. They aren't too spectacular, so I didn't take any pictures yet. :)
The case part received a small last-minute change:
In order to improve the logo on the backside, it was decided to make the logo surrounding with laser-cut aluminium.
Doing it fully in plastic would make it either look cheap or would extremely difficult to produce reliable and seamless.
The laser-cut aluminium will be a rectangle with rounded corners and the transparent logo inside.
I think you can imagine it a bit better with the picture found on the forum thread.
This does not cause a long delay, btw, as the change to the mold is minimal and while they were working on that solution, they simply continued to work on a different mold (the one with the DPad, as that is important so I can test the keymat and submit the final changes).
So I will get the molds in a different order than planned, but that's mostly it :)
Okay, what did Nikolaus do last week?
-------------------------------------
He didn't find the time yet to dive deeper into the stability issue as he would need a full day without any breaks for proper testings and he was a bit busy last week.
However, he continued to work on the remaining tests, and here's the current result (only the newly tested stuff listed):
* All SD Card slots are now working fine without errors in Linux
* Headset (incl. automatic switching and microphone) working.
* Vibra-Motor working
* Audio works
* Touchscreen works
* Display with rotator chip works
* USB ports work
Most other things (sensors, Wifi, Bluetooth, 3G/4G, keyboard, etc.) have already been tested before.
What's left to do before we consider the prototype finished:
* Fix the stability issue
* Test HDMI
* Test USB3.0 (we only tested the port with 2.0 so far)
* Implement and test the SDD AntiTear-Driver (code is almost finished)
* Test the fuel gauge and charging circuit for the battery
* Fix eMMC/MicroSD-Switch (needs a different part)
So... that's mostly it... the list was quite long a few weeks ago, now most of the main components have already been tested and confirmed to be working. Only a few things remain!
Want to leave feedback? Visit:
https://pyra-handheld.com/boards/threads/the-tests-continue.77003/
Sorry again for the long time without an update - once again, I'm stuffed with work... so running out of time.
This post will be a quick summary, but at least I'll have some nice pictures for you, which you can look at at the boards (link at the end of this mail) :)
Let's start with the status of the case...
------------------------------------------
The first parts of the case arrived last week (the full basement, so the most complex part).
And even though the last details to make it fit perfectly have not been implemented yet, it fits almost perfectly and looks and feels great!
The PCB fits perfectly, all ports and openings work without any problems as well, the keymat also fits fine.
The screws fit so much better than in the Pandora case as well (even though this is not yet the real material).
The shoulder buttons and the top of the case have been finished end of last week, so they will be shipped soon as well (I'll probably get them next week), the DPad and stylus should follow one week later.
So yes, we're getting there!
Okay, now we'll continue with the keymat...
-------------------------------------------
Now that I got the real case, I could finally start testing and tweaking the keymat as well.
Basically, it is working, but it needs some improvement:
The ABXY-Buttons need to be a bit higher. Right now, they don't stick out too much and when you press them, they are flat with the surrounding. This makes it hard to navigate from one button to the next one. I've checked different buttons (PlayStation and SNES controllers, Pandora, etc.), and they all stick out more than what we've got right here. This is an easy fix!
While the flat keyboard buttons look awesome, there certainly is a reason why all mobile keyboards I've seen so far are curved a bit. While typing works okay, accidental button presses easily happen, as the space between the keys is narrow. The mobile keypads solve that with a bit of an elevation in the middle and a recession at the edges of the key: Your finger automatically finds the absolute middle of the key, and as the area surrounding it is a bit recessed, you also don't easily hit that key. This also is an easy fix, I just need to do some more testing.
So not perfect yet, but we're getting there :)
And finally, the status of the PCBs...
--------------------------------------
As Nikolaus solved the issue with the I/O-Errors of the SD Card slot, he is now able to boot into Linux to do some testing.
Finally, we could test the remaining parts: The Wifi module (incl. Bluetooth) works fine as well, the LCD including the rotator work, the 3G/4G-Module works, etc.
However, there is one thing Nikolaus is fighting with right now:
The system runs a bit unstable if it uses too much power. Running two cores at the same time will cause the system to freeze at some time, running only one core will run mostly stable (except for if you stress the CPU).
This is another one of those issues where the solution will probably be simple, but finding it is a long and hard way.
He already traced it down to most likely be the charger / power management chip setup we're using.
It could be a software issue (both ICs are being configured by software during bootup), it could be a simple hardware thing where only a capacitor needs to be added.
This seems to be the last hurdle we need to take, as all the other hardware has been tested and is working already :)
Now, let's guess:
Will Nikolaus solve the issue or will all the case parts arrive here first?
My guess is that both will probably happen around the same time, which would make me a happy camper.
Want to leave feedback and see the pretty pictures? Visit:
https://pyra-handheld.com/boards/threads/an-almost-naked-pyra.76975/
Time for some (very very good!) news!
While I've been in Greece, Nikolaus has been busy as well, working on the CPU boards.
There was one nasty issue, that was hard to trace, but which has finally been found this weekend!
Which means: We're now 99,99% sure that the CPU Board is working perfectly fine!
And the mainboard looks great as well, but this will get more extensive testing during the next week.
So, what was that issue?
Well, while the CPU boards were booting, there were some CRC errors when booting from the first MMC slot on the mainboard.
Interestingly, this never happened when using the debug MMC slot which can be soldered directly onto the CPU board.
So... the question to solve was: Why?
Want to know why?
Then read on - otherwise, scroll down to the SNAP!
------------ SNIP! --------------------------
Was that a reflection from the bus from that debug MMC slot?
Were the traces to the SD Card slot on the mainboard too long and caused issues?
Putting a finger onto the open pads of the debug MMC slot caused these issues to improve... adding a capacitor there didn't do any fixes (and we couldn't deliver the Pyra with a finger included ;))
Also, some PCBs were not impacted by that issue at all.
And to put some sugar on top: It only happened with the first four tries. After that, the errors were gone and everything worked as it should.
Taking all that into account, it sounded like some tolerance issues - something which is annoying to debug... VERY hard and annoying.
So, based on what we knew, we suspected the following:
1. Open pads causing a reflection / receiving some other distortion signals
2. Timing issues in the MMC driver (software setup). Could also be timing issues with the DRAM, as CRC errors could also be the DRAM and not the MMC.
3. Too long traces which cause a bit of a power loss (would also explain why some work and others didn't, as all PCBs have a bit of tolerances).
4. Some other software programming of the power chip (the PALMAS) that causes the voltage to drop.
5. Soldering process issues causing bad contacts (which could explain why the work after a few seconds, as it makes good contacts when the chip is heated up a bit).
That was quite a bit of possible causes, and finding the real one was a VERY time consuming task.
Nikolaus spent a lot of time studying datasheets of the battery charger chip and the PALMAS power management chip. As the EVM doesn't have a battery charger, the setup is different in our case, so some software configuration for the PALMAS could be wrong.
And while he found some things that needed to be changed in order for the charger to work properly together with the PALMAS, it wasn't the cause of the MMC CRC issues.
Well, at least the work was not useless :)
As we use a different DRAM than the EVM, Nikolaus rechecked the timing settings as well and made a small program to test the memory.
This was time consuming, as every single change in the timing settings needed a recompile of the bootloader and another long run with the memory tester.
After one day, we knew that our DRAM is working fine - but still the MMC issue remained.
Testing with different temperatures (a cooled PCB, etc.) showed us that the temperature doesn't affect it. There were only read errors for the first few tries, then everything worked fine.
So no temperature problem (and therefore no solder process issue, which would've been bad).
So, next up: Figuring out whether the longer traces could be the issue.
A good idea is testing whether the second SD Card slot also has CRC errors, as the trace length is similar.
However, as the EVM only has one SD Card slot, the second one was not yet included in the bootloader.
Another task for Nikolaus: Adding the second and third SD Card slot to the device tree.
Once that was done, testings showed that no other SD Card slot had any CRC issues, so it's unlikely that the trace length itself was the issue.
So... what COULD be the issue?
What's different using the SD Card slot on the mainboard compared to the one on the CPU board?
Finally, Nikolaus found ONE thing that's different:
There's one condensator on the MMC bus which had been chosen for optimum GPS reception.
And yes: After experimenting a bit, Nikolaus found out that it was IN FACT the condesator!
A tiny change: Using 15pf causes CRC errors, using 12pf already fixes everything!
We'll use 10pf (to give it a bit more tolerance), and that's still good enough to not worsen the GPS reception.
That reminds me a bit of the wrong resistor Michael had to replace on the first few hundred Pandora PCBs, that caused Wifi to be horrible!
I hope I explained everything correctly - I might have not understood everything exactly and maybe have forgotten something, but it should be mostly correct :)
-------------- SNAP! -----------------------
Well, while it took a while resolving that issue, the good thing is that now all the other MMC buses are included in the device tree as well - that work had to be done anyways.
So, what's next?
Now that the CPU board is up and running, the next step is booting a real Linux system and testing all the remaining hardware components on the mainboard as well.
We don't expect many issues there, as a most of them had already been tested with the debug board and the remaining ones have already appeared on the bus they use, so that should be pretty straightforward.
After all, connecting and using sensors, Wifi modules or other chips to an existing I2C or USB bus is nothing hard (if Linux drivers exist).
I'll keep you informed, but it now put the biggest hurdle behing us!
Want to leave feedback? Visit:
https://pyra-handheld.com/boards/threads/next-huge-milestone-reached.76922/
