Now I am back to SPI driver for the microSD.
Thanks to Noltari, made such great process, this is the post http://vonger.cn/?topic=vocore-second-spi

SPI_CS1 is working normal now. We found the SD card not working is caused by the SPI speed is too high when SD card in init process.(Noltari SPI-GPIO firmware works, confirmed that is the problem).

RT5350 SPI lowest speed is 937.5KHz, but SD card init request speed is lower than 400KHz. It is a hardware broken.

But do not that hurry to say this SPI-microSD dead, let’s think this another way, at least, we have a temporary solution here 😀 Noltari’s firmware is able to make SPI flash and SPI microSD work same time already, just the boot time much longer, from 30seconds to 50 seconds..

We did not dead here yet. 😀 I think there still have some chance to make it happen.

What is SPI?
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus

How SPI transfer data?
From my understanding, SPI is working this way: Data -> Message -> Bytes
Data buffer is split into small messages, one message is about 512bytes, the bytes in the message are send through SPI one by one.
Message is the atom SPI operation. That means, it won’t change to other SPI attributes(such as clock speed, chip select, bits length etc) until one message is done.

Before message send, the upper SPI driver will call spi_setup to setup the transfer attributes(in rt2880-spi.c). The chance is here.

My plan is to combine the two SPI drivers, hardware driver and software driver. For high speed SPI devices we can use hardware(write to hardware register), for low speed(< 935KHz) devices we can use software(SPI-bitbang, write to GPIOs). From datasheet, the GPIO mode and SPI mode can be easily switched by writing to the pinctrl register. Just need some tricks to make sure the two drivers won't fight each other. 🙂 There will be a new powerful SPI driver for all boards have such problem, I'd better to patch this in spi.c but not rt2880-spi.c. About CPU consume, software SPI will cost a lot of CPU for high speed device, but for low speed ones, the performance is much better. SD card requested 400KHz for init only, so it just send hundred bytes, that cost can be ignored, so no effect to hole system.

Last week we are focus on the mass production.
From the beta production, we found some problems and that might lead to big problems in mass production.

1. Some parts in BOM are changed.
The factory engineer said they changed the BOM parts by their exists parts. That is a default rule, so they did not notice me that.

Before production, we found the flash chip was changed from W25Q64FVTIM to W25Q64FVSSIG. There are two kinds of alpha board, 200pcs are using W25Q64FVTIM, and 100pcs are using W25Q64FVSSIG. W25Q64FVTIM is 1mm tall, same as SDRAM, W25Q64FVSSIG is 2.3mm tall. W25Q64FVTIM cost is 30% higher than W25Q64FVSSIG and it is rare in market. W25Q64FVTIM is the only prefect one due to its small size and later hobbyists can easily hack it to other SOIC8 chip(VSOP8 is compatible with SOIC8).
PS: current mass production buy out all exists W25Q64FVTIM in ShenZhen electronics market. 😀

When I get the demo board, I found the power inductance is changed from LQH2HPN2R2MJ0L to SWPA252010S2R2MT(final version it is SWPA252012S3R3MT). From datasheet, Sunlord one have better performance in higher current(>600mA) but its resistance is 0.21ohm compared Murata one is 0.14ohm. So that might make the power consume a little higher, about 0.015w. This is not prefect, but acceptable due to better performance.

2. Test process.
They are using QA tool for mass production quality test, that tool is mainly used for router and phone(that factory is big, main job is to make router/phone parts for Samsung and TP-LINK) but never did such develop board for hobbyist. OpenWrt wifi driver do not support QA tool due to it do not have RT5350 native io control. I want VoCore to have a prefect quality, so it must use the QA tool. We use RT5350 SDK to run QA then flash it to openwrt for other tests. That process is complex and the factory is unhappy, I have to code a helper application(auto test from telnet/serial), also this app helps the factory to test their other production, so they are happy after that, and no manual operation also helps VoCore avoid test mistakes. 🙂

3. Packages.
There are thousands of packages contains different perks. That is a big work. I write a small application to filter the packages, about 2200+ packages are normal, but hundreds of packages are incorrect. Some only have Dock but no VoCore, some addresses are not right, have to email them later and deal manually. If I have next crowd-funding campaign, I will make the perks as simple as possible. 🙂