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 will require a costly respin of the motherboard. And how exactly does one choose a specific LCD module XYZ from manuf ABC when there are some 10 or 20 different LCD manufs trying to get our business? (Yes, that is how the Chinese market works - post an RFQ on Alibaba and get flooded with product offers.) What I've done so far is that I selected 3 vendors for further evaluation based on the datasheets they sent me, and I have ordered sample pieces for evaluation from all 3 of them. One of these 3 vendors unfortunately turned out to be rather sleazy: their original datasheet said 6:00 viewing direction, but now the guy is telling me that the samples pieces they sent me are for 12:00 viewing direction and that they will make the 6:00 version when we go into volume production. I told him that he and his company are NOT going to get our business unless they send me evaluation samples (*before* we commit to them as our vendor of choice) with the polarizer film put on for the 6:00 viewing direction (NOT the 12:00 direction which seems to be the industry's favorite for some reason beyond my understanding); I haven't heard back from him yet, but I am already refocusing my attention on the other two vendors' modules I've selected for evaluation. Vendor 2 seems to be in the process of preparing the shipment of their sample pieces, and I haven't heard any shipping updates from vendor 3 yet. Once I actually receive some LCD samples in my hands (at least one of the vendors already shipped theirs, tracking says I am supposed to get them tomorrow, but it's the one with the wrong viewing direction), my plan for testing them is to connect each LCD under test to an FT2232D adapter in the MCU host bus emulation mode - this FTDI mode emulates an 8-bit microprocessor bus and can be used to drive a parallel MCU-style LCD in 8-bit mode. Then write a Linux PC host program to program the LCD controller and display test pictures by talking to the MCU-host-bus-emulating FT2232D via libftdi. One of the 3 LCD vendors I've been dealing with said they would include a breakout board with their LCD samples that brings all of the LCD module's signals to header pins; if I actually receive the samples from this particular vendor and if there is indeed a fitting breakout board included, I will test that vendor's LCD first, using their breakout board, one of our existing FT2232D breakout boards and some hacky breadboard to make those connections that aren't straight 1-to-1. Otherwise I may have to design and build a special LCD test board, which was my original plan before one of the 3 vendors dropped the 12 o'clock surprise on me. All in all, a huge mess, but it needs to be done. Hasta la Victoria, Siempre, Mychaela aka The Mother _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community