Just waiting for factory…So I am on SPI again. 🙂

Last time I have done the driver, but it is not working with mmc. I think there must be something wrong with it, but after my test, the driver works quite well, so I guess I should make some mistake in mmc driver config.
NEW SOURCE CODE HERE: spi-rt2880.c

I soldered another flash to a bare VoCore board, so I do not have to solder the eight wires. Connect CS1->CS0, SPICLK->SPICLK, MOSI->MOSI, MISO->MISO, also pull HOLD/WP to high, so now VoCore SPI1 is controlling the second flash.
It works very well by current openwrt in high speed(>935KHz).

Add the following code to replace spidev@1 in VOCORE.dts, set the flash to 500KHz.

m25p80@1 {
    #address-cells = <1>;
    #size-cells = <1>;
    compatible = "w25q128";
    reg = <1>;
    linux,modalias = "m25p80", "w25q128";
    spi-max-frequency = <500000>;

    partition@0 {
        label = "xxxx";
        reg = <0x0 0x1000000>;
    };
};

Hardware part connection:

From my test, the data is normal.

root@OpenWrt:/sys/devices/10000000.palmbus/10000b00.spi/spi_master/spi32766/spi32766.1# ls
driver      factory_id  modalias    mtd         subsystem   uevent
root@OpenWrt:/sys/devices/10000000.palmbus/10000b00.spi/spi_master/spi32766/spi32766.1# cat factory_id
D26210-44DB40312F

Its log:

Mon Sep 29 02:06:27 2014 authpriv.notice dropbear[1175]: Password auth succeeded for 'root' from 192.168.61.159:58928
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1461.940000] m25p80 spi32766.1: low speed mode.
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1461.960000] m25p80 spi32766.1: delay = 1000
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1461.970000] m25p80 spi32766.1: low speed mode.
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1461.980000] m25p80 spi32766.1: delay = 1000
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1461.980000] m25p80 spi32766.1: cs = 1, on
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1462.000000] m25p80 spi32766.1: bit/x: 8,5
Mon Sep 29 02:07:19 2014 kern.warn kernel: [ 1462.000000] m25p80 spi32766.1: low speed mode.

Read data from the flash is also normal, just a little slow:

root@OpenWrt:/# hexdump -C /dev/mtdblock6 | head -10
00000000  27 05 19 56 d6 62 66 a6  53 88 7f 17 00 01 96 c0  |'..V.bf.S.......|
00000010  80 20 00 00 80 20 00 00  a3 c1 ed e5 05 05 01 00  |. ... ..........|
00000020  53 50 49 20 46 6c 61 73  68 20 49 6d 61 67 65 00  |SPI Flash Image.|
00000030  06 50 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |.P..............|
00000040  ff 00 00 10 00 00 00 00  fd 00 00 10 00 00 00 00  |................|
00000050  e9 01 00 10 00 00 00 00  e7 01 00 10 00 00 00 00  |................|
00000060  e5 01 00 10 00 00 00 00  e3 01 00 10 00 00 00 00  |................|
00000070  e1 01 00 10 00 00 00 00  df 01 00 10 00 00 00 00  |................|
00000080  dd 01 00 10 00 00 00 00  db 01 00 10 00 00 00 00  |................|
00000090  d9 01 00 10 00 00 00 00  d7 01 00 10 00 00 00 00  |................|

I think last time I should did something wrong in the mmc driver config…

Many people ask me about how to pass the FCCID. In fact, the process is not that complex.

That is benefit to there are many module companies’ productions are using RT5350 in ShenZhen, and the foundry I choose has such production already(they also many good software, I am free to use). So I just send VoCore sample to the laboratory, and leave the foundry engineer’s phone number to the laboratory, they did rest for me, that saved me a lot of time.

PS: before the sample send to Lab, the beta version has already tested in factory, all results look good, so my confidence is from there.

About the sample, first of all, the board must in good quality. I am not sure what test they will do, but if the quality is not good, it might broken in half way. My samples are made by machine, better than my hand make ones.

About the test process, I knows little about that, I only know if the EMC can not pass, the laboratory will ask you if you want to add a metal shell, then do the test again(of course, your FCCID production photo will show the shell too, and your final production must have that metal shell)

VoCore passed FCCID in one time without any shell, that should thanks to the simulation software, when I design it, I set its simulation parameters to 1GHz, 3.3V to all traces, the sim result max crosstalk voltage is under 60mV, it should be a good result due to other board such as RM04 the crosstalk value greater than 300mV, its 30% traces even more than 800mV, maybe such reason they have to have a shell. The software I used name is HyperLync. 🙂

To lower the crosstalk voltage, we must keep trace distance 3W at least. And the trace should as short as possible.

Autumn comes, my house temperature is 25C, and test on new VoCore with dock several hours, the max temperature on the surface is lower than 50C, very good 🙂 not hot anymore, just a little warm.

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