Portable F103 - Misc items

Projects / F103 Pod

32kHz oscillator start up issue

I ran into a bit of oscillator start up issue with the 32kHz crystal.  I don't know if it is because of the corner cases of the cheap STM32F103 chips combined with the 32kHz crystal I pulled from a PC motherboard that doesn't satisfy ST's recommendation of load capacitance and bad luck.  Looks like it could be VBAT is out of specs and that might have damaged the internal circuits in the process. 

Anyways the symptoms seems to be that from time to time the crystal would take a long time to start up and occasionally fails.  My code was waiting for RCC_BDCR_LSERDY.

So I looked at the signal levels at the oscillator pins and found that PC15 (OSC32_OUT) was at 3.2V where as PC14 (OSC32_IN) was near 0V.  There was something funny about this as there was supposed to be an internal feedback resistor that should make the inverter linear at about mid-rail.

I measured a DC resistance of about 2.8M to ground on both input and output pins.  Not sure why it was grounded at the middle.  Could that be a fault due to handling?  Or that it was damaged by me violating the VBAT specs.

I read the following from an article (.pdf)  They recommended 10-15M feedback resistor for 32kHz. Higher resistor values means higher gains.

I looked at a few of the PC motherboards and they all have a 1M resistor, so I have decided to take one from the motherboard and solder in parallel to the oscillator pins.  It doesn't hurt if the oscillator passives are close to the values where I got the crystal from.  I do however recommend to follow ST guideline whenever possible.

Both the pins are now at 1.6V and the start up issues seems to be cured for now.  I have made the changes to the PCB layout for an optional resistor.

It seems like the VBAT circuit might be the cause of this issue. I used two silicon diodes to reduce the voltages from battery.  In LTSpice, the voltage drop works out to be 0.6V at 1uA and in theory that should satisfy the maximum voltage.

I operate the board without the battery attached for development as I might need to solder or probe things.  The LiPo charger is in float charge mode, so UB+ is always around 4.2V.  With the battery attached, the charing would have been stopped and would not see voltages this high that often.

The problem is that the Power Switch circuit bypasses VBAT when VDD is present.  There might not be sufficient current drawn to maintain a high enough voltage drop. I have decided to add an additional load at output of the diode with a 2.7M resistor.

LiPo capacity estimation

I have decided to estimate the MP3 player battery capacity by weight.  I gathered a few LiPo batteries of the same pouch style from my collection.  Unfortunately I don't have enough for a reliable estimate, but I think they are better than not having one.

The "400mAH" was a aftermarket replacement for the ipod mini. Apple had a recall of the ipod because of battery issues, so I swapped the my replacement back out.  The "180mAH" one was from a picture frame and the two smaller ones are from 2 different models of the MP3 players. I trusted the "180mAH" battery capacity a bit more as it was a part in a product not directly sold from China.

It works out to be about 41.86mAH per gram. The battery weights which is mostly composed of the chemical ingredients are used as a ratio for the estimate. I think the numbers are close as the capacity are close to rounded numbers. The larger MP3 player battery is close to my initial 100mAH estimate.

The power consumption of the STM32F103 could be reduced by running at or below 12MHz while on battery.

Portable F103 - LCD

Projects / F103 Pod

I am working on initializing the LCD.  I don't have much luck getting my code to initializing the LCD reliably.  My experience tells me that if I cannot obtain official info, I should do the hard work myself than to rely on unreliable 3rd party sources..

LCD have specific parameters, so what better place than directly reverse engineering from the player itself.

Probing SPI from the LCD pads

Delay after /Reset deasserted to initialization sequence

There is a delay of about 26.6ms from the final rising edge of the /Reset line to the assertion of the chip select line on the LCD.

I have captured the following LCD initialization command sequence.

LCD Init code

The code sequence:

E2: Reset
A2: Set bias = 1/9
A0: Seg direction - LC[0] = 0
C8: Col direction - LC[1] = 1
26: Resistor ratio = 6
2F: Power control: Boost, Reg, Follower
40: Set Scroll Line = 0
A0: Seg direction - LC[0] = 0
AF: Set Display Enable

81, 02: Contrast = 02 - They probably change the contrast to a bit higher after the bitmap is loaded.

This is the data rate for initialization command.

SPI data rate

There is a delay of 6.6ms after the initialization sequence before the bitmap data are sent.

Delay after init commands

The data rate for the bitmap is 1Mbps.

Each of the lines started with the command sequence

1x: Set Column Addr 
0x: Set Column Addr 
Bx: Set Page Addr

and followed by the bitmap.

Here is a quick test using my Nokia 5110 LCD routine.  I am using 9Mbps. I have yet to add in the proper delays.

LCD controller is uc1701​,  Datasheet (UC1701.pdf)

I find one gotcha that evaded me for most of the afternoon. I got clued in when my display stopped showing garbage when I cranked the data rate up to 36Mbps. (The part is rated for 33MHz.)
I have forgotten that SPI has a (single byte) buffer. If I need to switch between data and command mode, I have to wait for the current transfer to finish. That's what the while loop does.

I'll keep the SPI data rate at 9Mbps so that I can use a slower GPIO slew rate (10MHz) for  to minimize signal quality issues as the flex circuit on the LCD module doesn't have a ground plane.