Re: FCDEV3B sleep mode bug update
Hello FreeCalypso community, With April Fools silliness out of the way, I have some real news regarding the progress of our family of projects. The first update is that I have progressed one more step in the sleep mode bug investigation. With help from our dear Das Signal, I learned how to convert one of my oscilloscope probes from the hook type to the needle type, and I was then able to use this o'scope probe to observe the FDP signal (Calypso output) on a decased Pirelli motherboard. I powered it with alligator clips on the spring contacts of the battery connector (a total hack, but I got the clips to stay connected and not short for the duration of the experiment), loaded an AT-over-RVTMUX Magnetite fw build via USB and fc-xram (connect USB with no battery power, run fc-xram, then apply power to the battery contacts), and observed the FDP signal that comes out to an unpopulated 0402R footprint with different AT%SLEEP settings. The observation of this FDP signal confirmed my hypothesis: it does go low in all sleep modes including small sleep, but stays a constant high when all sleep modes are disabled. Consequently, my bigger hypothesis that having this FDP signal connected to the flash chip's reset input is what causes the sleep mode bug (because of it going low in all sleep modes and jerking the flash chip's reset line) is still plausible, and is supported by the observation that on Pirelli's board this FDP signal does NOT drive the flash reset line - that resistor is unpopulated. The next step will be to try a very delicate surgical experiment on an FCDEV3B: remove the flash+pSRAM chip (BGA rework station to the rescue), cut the trace between the D5 ball pad (flash reset) and the microvia it goes to, make a solder bridge or some other hacky connection to the C5 ball pad next to it (WP#/ACC input, connected to flash Vcc through a pull-up resistor), and then put a new S71PL129NC0HFW4B flash+pSRAM chip back on (BGA rework station once again). The effect will be to disconnect the flash chip's reset input from FDP and tie it high instead. Then see if this hw change makes the sleep mode bug go away. I am going to email Technotronix and ask them if they can do the just-described feat. The other big venture I've been doing is dealing with several different LCD manufacturers in China, trying to find a suitable LCD module for our FC Libre Dumbphone handset. My display size requirement is 176x220 pixels (color TFT), chosen for two reasons: (1) so that the first prototype of our handset can also serve as a replacement for TI's D-Sample, and (2) to maximize our ability to reuse TI's existing starting-point UI code that is written for this display size. The second requirement after the size is that the interface needs to be 16-bit parallel (as opposed to 8-bit parallel or SPI, which are the other common options in the industry); this requirement is driven by performance considerations: both the D-Sample and the Pirelli have 16-bit LCDs, wired such that each RGB565 pixel is sent to the display with a single Calypso ARM7 write cycle, and I am not comfortable with using a slower LCD interface in our own design. The third and final requirement is that the LCD needs to be designed for 6 o'clock viewing direction, as that is the direction from which the display on a cellphone handset is going to be viewed. I used to be a big fan of Crystalfontz, a USA-based distributor of LCD modules who generally have good technical documentation for their LCDs and offer all of their products in a hobbyist-friendly manner with no MOQs, but their 176x220 module only brings out 8 data lines; the actual controller in their LCD is 16-bit-capable, but only 8 lines are brought out to the FPC tail. I asked them if they could make a modified version with all 16 lines brought out, and they responded with a price figure that is not reasonable for our little project. So I went to Alibaba (the Chinese market) and found that quite a few of those Chinese manufacturers already have 176x220 pix 2" TFT LCD modules that bring out all 16 data lines plus the IM0 configuration pin, so the LCD can be used in either 8-bit or 16-bit mode. The big difficulty is that the details of the LCD interface (whether the FPC tail is soldered down or goes into a ZIF connector, and the exact pinout of this connector or solder-down tail) are different for each manufacturer's LCD module, not standardized in any way. It is therefore not possible to design a handset motherboard to accept "any" LCD module and let various manufacturers compete for our business at some far future date when we go into volume production, instead we have to design our motherboard for some specific LCD module XYZ from manufacturer ABC from the start. Changing to a different LCD module from a different manuf further down the line (for example, if our originally chosen vendor goes out of business or starts demanding an unreasonably high MOQ*unit_price product) will be possible, but
Re: FCDEV3B sleep mode bug update
Hi DS! > First of all, congratulations on this new breakthrough! Well, it is not quite a breakthrough yet, only a hypothesis (so far unproven) that FDP going low during sleep and driving the flash reset is the culprit, but the fact that the Pirelli has FDP disconnected from this flash reset line is strong evidence in support of it. We still need to test it properly to be certain. > About the new batch of FCDEV3B: as this would be quite expensive, > don't you think it'd be perhaps best to set this money aside for the > next step of FC hardware, namely the handset? Yes, I will need to give it some more thought. At the minimum though, we still need to do the probing test on a decased Pirelli motherboard (where an unpopulated 0R footprint can be used as a test point) to confirm if indeed Calypso's FDP output does what I think it does, and the surgery experiment on an FCDEV3B to see if my proposed change will make the problem go away. Even if we end up never making a corrected FCDEV3B batch, knowing the fix would be valuable for answering potential buyer inquiries, and of course we would need the same fix for the HSMBP, hence knowing it would be a great peace of mind. > As I imagine the costs > to create a handset would be very large and may require a lot of > cash upfront, every amount would count. Actually I do not currently anticipate a single large upfront cost that has to be paid all at once, instead over the course of the year or two that it will take me to do the design, I anticipate having lots of little expenses here and there, primarily for hiring outsourced help for various little steps which would be too difficult for me to do on my own. Here are some examples: * I am currently in the process of evaluating LCD modules from 3 different vendors, or more precisely, in the process of ordering sample pieces for evaluation. The cost of these sample pieces themselves is negligible, but in order to evaluate them, I may need to make a little LCD test board. * As far as serial interfaces go, I am pursuing the following arrangement: the MODEM UART will be brought out on the handset's USB port via a CP2102 or FT232R chip, combined with charging, whereas the IrDA UART will be brought out to a debug connector together with JTAG. The debug connector will take an FPC cable going to a FreeCalypso debug adapter board, and the latter will be nothing more than an FT2232D adapter with the special connector. The principle is exactly the same as Openmoko's debug board, but the debug connector pinout and form factor will be copied from the Pirelli. I will need to have the modified FT2232D adapter board and the FPC cable made, and I will test these pieces against a decased Pirelli motherboard ahead of our own HSMBP. Building the debug tooling for our HSMBP ahead of the main device itself is the hardware engineering analogue of test-driven development in software, where you write the tests ahead of the production code to which they apply. * Once I get to doing the schematic-level design of the HSMBP itself, I would really like to be able to get some hired help from someone who is more of an EE than I am. I would like to have a backlight driver circuit that produces the same current through the LEDs regardless of the battery state of charge and thus the voltage; a plain series resistor won't do the trick, and I would like the help of a real EE (which I am not) to come up with a smarter circuit, ideally one that is also more efficient than a voltage-dropping series resistor. I may need similar EE help in some parts of the audio subsystem and with the charging circuit. * I am tired of being held hostage to proprietary tools, hence my plan with the HSMBP is to bite the bullet and do it properly in a FLOSS PCB layout tool. KiCad is a turn-off for me, but pcb-rnd has been making great progress lately, and it appears to be very close to a state where it could do the needed job. But I will probably need to offer some $$$ to a pcb-rnd developer to implement some finishing touches which we need but which others apparently don't need, and which would therefore not get implemented organically. As you can see, there will be a cost associated with each of these steps, but they are relatively small costs which would need to be paid to different people for entirely unrelated jobs, and can therefore be spread out over time. I will write more later, but I am very tired right now, so I am just getting this reply out with my current not- quite-finished thoughts. M~ ___ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
