Now, looks like everything is back to normal, all parts are ready now.
This is the ship time update:
If no big issue again, VoCore will be in SMT line about this Wednesday.
SMT will be done about this Sat, then test will take 3~4 work days.
Sep.30~Oct.6, the seven days is China National Day, so factory will not do any work.
Today will prepare the early bird ship.(early bird with dock will ship with the composed batch).
Oct.7 will ship the VoCore without dock.
VoCore + Dock(solder the pins, compose VoCore & Dock, package and test) will take about 5~7 work days.
So composed VoCore + Dock will ship about Oct.13~Oct.17.

From the factory, all docks are ready…

(The pictures are not the final one)

(Still need to solder pins)

(Still need some clean up)

Bad news and good news.

Bad news first: The factory get wrong chip type…I need W25Q64FVTIM(3.3V) but they get W25Q64??TIM(1.8V). The engineer find that when they count the chips…And even worse, all W25Q64FVTIM has sold out(I think winbond should thank to my ‘ advertisement’, due to last half year, nobody buy that chip) Next batch of chips have to wait at least four weeks. That means the ship time will be next month.

I hate Murphy’s theorem :'( There are a lot of people waiting, I can not hold…

Good news: There are some W25Q128FVTIM in store, at least enough for my first batch 🙂 All indiegogo VoCores will upgrade to that chip, means the flash is upgrade from 8MB to 16MB, free. And for Limited version without dock, will have a free DIY dock; Limited Version with dock will have a free shell(made by 3D printer).

Sorry for the delay, hope everyone have a happy day. 🙂

It is a long time 🙂 I am back to SPI & MicroSD.

PS: PCB is ready today, and the boards has send to SMT/PCBA factory. Now the factory is counting the parts, the PCBA and test will start right now. Nothing is as easy as it looks. (Haha, Murphy’s theorem 🙂 )
Paypal is working now, finally…

After some dirty and dark code, RT5350 SPI driver function is almost there. (still need some fix and clean up the code!! I hope that will be done tmr 🙂 ) This code might help if anybody already on such thing.

The code is dirty, due to I write to SPI/GPIO register directly.
(I have read all pinctrl source code, all spi driver code, all spi-gpio driver code and related code, not exists such api/interface)

Code can be find here.spi-rt2880

What I have done:
1. setsck, setmosi, getmisi, chip_select, all functions work.
2. The pins(clk, mosi, miso, cs0, cs1) work normal in GPIO mode.
3. low speed mode (< 937.5KHz) and high speed mode (>= 937.5KHz) is able to switch smoothly.

Exists bug:
1. tf card plugin but the driver can not detect.
2. weird result from spidev_test.

root@OpenWrt:/dev# spidev_test -D/dev/spidev32766.1 -s10000000
spi mode: 0
bits per word: 8
max speed: 10000000 Hz (10000 KHz)

50 3F E0 00 3F FF 
FF FF FF FF FF F0 
5F FF FF FF FF FF 
FF FC 17 FF FF FF 
FF FF FF FF 05 FF 
FF FF FF FF FF FF 
C1 7F 
root@OpenWrt:/dev# spidev_test -D/dev/spidev32766.1 -s300000
spi mode: 0
bits per word: 8
max speed: 300000 Hz (300 KHz)

FF 05 FF FF FF FF 
FF FF FF FF FF FF 
FF 01 FF FF FF FF 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
FF C0 

Note:
1. Directly write to register might collide. Pin control has a lock for that, but my current code do not care about that.
2. I do not worry about high speed/low speed change, there is no conflict. SPI doing its work in its own worker thread, one thread for one master, data is safe here.
3. CPU consume is low 🙂 Looks like this is a right way if we fix the bugs.

Any idea is welcome and appreciate 🙂

Last week I have been to the factories, the mass production is already online, but we still have to wait.
And recently it happens to be China Mid-Autumn Festival, so now all of the workers are on holiday, that delays the production time. For now, I just get 150pcs from the beta batch.

Mass production is totally different from small batch.
1. PCB test cost over three days(not done yet due to the festival holiday), but small batch(<1K) only several hours. 2. The antenna cost 2~3 weeks to prepare from the provider. They said it will come in this week. 3. The SMT test and flash openwrt, might cost 5 work days. Hope these are all the problems and do not delay too much. I am trying my best to speed up the project process. PS: Do NOT use the **** PayPal for your crowd-funding, I did not get a coin from it yet(two months), even the money from my old projects is freeze.(I mentioned FCCID when I call them, then they said they will not release the money until I get FCCID, but I will only get FCCID unless I have some samples, even worse, that sample must be same as the final batch…) Have to borrow some money from my friends for this mass production… No matter how hard the choices are, life must go on, right?

view or download manual here(7.6MB):

vocore.manual.pdf

Good news is FCCID test is done and VoCore passed the test. From the laboratory, they said they have send the result to the US Federal Communications Commission. If everything goes well, we will get the FCCID next Monday. 🙂 (FCCID is not that easy to pass! The laboratory said some values are almost touch the edge, but VoCore is the final lucky one. I did not get the test result yet, they will send to me once they get the FCCID)

FCC requests me add one line at end of the manual:
Keep this module >20cm from body when WIFI is on.
(Or I will have to do SAR, another test)
I do not worry about the wifi, but the naked RT5350 chip is very hot(60~70C), so we’d better keep 20cm from it. 😀

Shell File: Download Here

Weight:
3.0g VoCore
6.0g Shell
20.0g VoCore + Dock + Shell

I need to export flash factory id to user space, but current m25p80.c do not support that. My old blog has get that id, and output it into log.
Now move a little forward, show it in user space.

We can get the id by cat its interface.

cat /sys/devices/10000000.palmbus/10000b00.spi/spi_master/spi32766/spi32766.0/factory_id
D16330-6417232123

The code is simple, need to change two parts of the source.
First add attribute to m25p80.c

static ssize_t m25p_factory_id_show(struct device *dev,
    struct device_attribute *attr, char *buf)
{
    const struct spi_device *spi = to_spi_device(dev);
    u8          code[5], id[8];

    code[0] = OPCODE_FACTORY_ID;
    if(spi_write_then_read(spi, &code, 5, id, 8) < 0)
        return sprintf(buf, "\n");
    return sprintf(buf, "%02X%02X%02X-%02X%02X%02X%02X%02X\n",
        id[0], id[1], id[2], id[3], id[4], id[5], id[6], id[7]);
}

static DEVICE_ATTR(factory_id, S_IRUGO, m25p_factory_id_show, NULL);

DEVICE_ATTR is used to declare attribute, it has four parameters:
factory_id is the name, that is also the attribute file name in sys folder.
S_IRUGO is the file access privilege, S_IRUGO = r--r--r--
m25p_factory_id_show is a callback once user call standard read through factory_id(that sys attribute interface file).
NULL is a callback for standard write, but we do not need that for current usage, so it is null.

OPCODE_FACTORY_ID is 0x4b, that is from datasheet. Looks like every SPI flash chip has that interface and a factory id, so why not make it as a public attribute?

Now, the attribute interface is ready.
We put the following code into m25p_probe(before return), so once the driver is ready, this attribute will show in the sys folder.

    device_create_file(&spi->dev, &dev_attr_factory_id);

Also will commit a patch to openwrt.org, need some time learn how to do that. 🙂

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. 🙂