Recently I get around 10pcs broken ones returned. Is it really the mystery ESD problem or something else? Let’s analyze one by one check what is the problem. Hopefully this blog will also help DIYer find a way to solve such problem.

1.Obvious physics broken ones:

Four screens has such problem. Red rectangle area is the weak point.

Left FPC 51p is for screen and right 8p is for touch screen. From the picture, the 51p and 8p both tear off by force. FPC is something like tape, it is afraid of sharp edge. Such problem normally happens when you bend the FPC hard, and FPC touch the PCB or the connector edge, it will be easily broken.

Recommend: FPC better to have a beautiful round corner, this will reduce tear off chance, also use the bubble tape around 1mm to stick it to PCB or back, NOT recommend use the hot melt adhesive, it is bad to fix the PCB because there are so less margin after it becomes solid, that will cause it easy to broken FPC.

2. Hidden Physics Broken

This screen problem is when we run test application send_frame frame.dat, its backlight will not able to turn on. One of broken screen is such problem. After remove its touch screen, I find the FPC is normal, but the liquid crystal driver chip is shattered. That driver chip is like a very thin glass, and when people is trying to force the glue on FPC off its holder, it will have very high chance to broken that chip.

PS: this part debug is a pain, last year on another project we use this screen, around 20pcs broken because of such problem, workers mistake stick the bubble tape to this area so when we remove the screen to repair other parts the screen broken by the force.

Recommend: tape or adhesive leave far away from this area! Do not touch this FPC at install. New version screen do not have such problem, but we still suggestion do not put any tape or adhesive on the FPC area, it should be only on the steel part.

3. Not Well Connected

One broken because of this reason, this screen also has FPC tear off problem.

Recommend: please do not use adhesive… 🙁

4. Firmware Problem

Rest screens are all such problem. This problem I never expected. That just is the unknown device problem. This should not happen if the screen is operated normally, I guess maybe some client side code has bug, I will check with SimHub developer.

For my MacOS or Linux, we have lsusb command, it will show the device like this:

Bus 020 Device 005: ID 04b4:8613 Cypress Semiconductor Vendor-Specific Device

If firmware is normal, it should be like this:

Bus 020 Device 011: ID c872:1004 c872 USB2.0 Screen

The firmware is written in EEPROM, and it should never lost any data unless client side application write something wrong to it…This is very weird.

I attached the firmware loader(download here), this application only run in MacOS.

For PCB version v05 and v07a, please call

./eeprom w ./FW200502-4IN14V.bin

For PCB version v10a, please call

./eeprom w ./FW210105-4IN3V3

After firmware upload completed, disconnect and reconnect the USB cable, all of the screens has such problem are fixed.

So the final result, none of the driver board are really broken 🙂 Just the physics broken screen we can not fix have to change screen. All 10 of them are repaired.

5. USB cable problem

This is not belong to this part but also very important, please use a short or well covered USB cable. This screen used max USB speed, every data line is 480MHz, so a bad quality USB cable will not make it work, will cause sometimes the screen can not be recognized or show some random noise on the screen. We also think the firmware is broken by this way. This need to be confirm.

5inch 480×854 screen is almost ready 🙂 Compare to current 4inch one.

Recently some people report to us one problem. After they power on computer, VoCore Screen can not be found anymore, it become an Unknown Device. Currently the bad ones are on their way shipping back to us, but for now, I think I can guess what is the problem already.

It is a very weird issue, because our screen is already in some projects and pretty stable for two years, should it be the chip become bad for this batch?

Interesting thing is our embed users never report such problem but only PC users who using the screen as an extend screen run SimHub has such problem.

So, it can not be the chip problem…If there are some problem, it must be ESD!

The critical problem should be the USB data line do not have TVS diode protected. And USB data line is weak to strong noise, strong EMI will broken it from inside. But where is the noise from?

After a lot of check with the client, the truth comes up. Normally Simhub users are using a very powerful PC who has a big power supply, some times the user will open the PC metal enclosure for better cooler, then the room become a hell of the screen driver board… because it do not have any protect. :'(

I have to say it is my design flaw, this screen is designed for VoCore2, it is not designed to use in such situation. Normally for embed usage, the USB cable is very short and well protected by ground, it is not necessary to use TVS diode to protect the USB. But PC…ahhhh, PC is another story.

OK, let’s talk something hardcore…

Solution for current version

PS: I know it is stupid…but in order to increase the board life, it is necessary

• solder two TVS diodes to the USB cable D+/D-.

• connect the screen after you power on your desktop PC.
• cover the EMI source with metal case, to reduce the power on/off ; noise. (noise mainly from power on)
• a well protected/short USB cable also work.

Note: TVS diode capacitance should be < 3pF, voltage 3.3V or 5V.

Any of the three way will work.

New screen shipped from Mar.25 will default have the protect diode solder on bottom side.

Update: we finally get some broken samples…but none of them are broken by ESD, all broken by force install caused PCB bend, chip is not connected well to PCB.

Update: v7a/v10a driver board is designed for embed device, not test on PC. From Oct.1, 2021, we have v7b/v10b version, special optimize for PC, fixed such problem.

Source code of fbusb link: https://github.com/Vonger/vocore2/tree/master/utils/fbusb

Directly Compile in Linux(raspberry pi)

This is tested on raspberrypi, it should be also working on another Linux system. Please go to fbusb/src folder then run this command.

make -C /usr/src/linux-headers-$(uname -r ) M=$PWD modules

After this command, you will get fbusb.ko

Cross-Compile for OpenWrt in MacOS

Cross compile is similar. For example, I want to compile the driver for the VoCore on my Macbook, I will need to go to fbusb driver folder first, then run this command:

make -C /Volumes/OpenWrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/linux-4.14.195 M=$(PWD) CROSS_COMPILE=mipsel-openwrt-linux- ARCH=mips

This path /Volumes/OpenWrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/linux-4.14.195 is my Linux header path, You need to change it to yours.

VoCore Screen is mainly designed for embed Linux, so it is easy to work on Linux or Unix(MacOS), but for windows, it is not that smooth. Windows do not have libusb support directly, so we have to use third party driver to achieve that, like libusbK.

Recently pretty much people use this screen for car race simulator on Windows, so I think it is necessary for me to write a tutorial to show how to fast test if the screen work normal under Windows OS.

First, we need install libusbK for Windows

We already have it in our windows SDK, you can download it at vocore.io/screen.html, or use this directly link here: http://vonger.cn/misc/screen/v2touch-win64.zip, uncompress it and install the libusbK driver, you can find the device “USB 2.0 Screen” at your “Device Manager”.

Second, try our new test app in SDK.

In v2touch-win64.zip, there is one folder named example, used to test the screen.

And we have a test data, frame.dat. So we can directly run send_frame in the example folder in windows command line.

send_frame frame.dat

Then your screen will display the test picture. Test picture should be 480×800 size and 16bit RGB format BMP, remove 139 byte BITMAP header, raw data.

Other Commands Usage

send_frame

• usage: send_frame [frame data file]
• used to send one frame(bmp 16bit format data without bitmap header) to screen.
• example: send_frame frame.dat

read_touch

• usage: read_touch
• used to read touch screen position and press status, no parameter.

send_cmd

• usage: send_cmd [cmd] [param]
• used to send command to screen, control screen rotated or backlight.
• example: mirror by axis x,y [0,1,2,3] to mode1 send_cmd m 1
• example: set backlight [0~255] to 120 send_cmd b 120

From last year Sep.1, we meet global chip shortage. Recently some chips price increase to incredible level. My chip provider told me, currently STM32F103 price is around 72CNY/pcs(11USD/pcs) compare to early of last year only 3~5CNY. Another network chip IP101G, from 0.8~1CNY to 10CNY. 🙁 This is really crazy.

PS: Lucky, I use Gigadevice MCU, pin to pin STM32 but need to recompile firmware. Its price increased 10%~15%, compare to STM32 chip, looks like it is reasonable and acceptable.

For our production VoCore2 and camera, we have enough stock, but screen driver chip now have problem. The chip factory give me 25~30 weeks lead time, that is over half year. We have to change current screen plan.

New screen is from Toshiba, better color than our old one. In order to compatible with old design, we add a FPC to convert its connector. For order later than Feb.9, we will all ship this screen. In software level they are compatible.

One slight difference, old screen once power on will show a white screen, this new one show black screen as default.

Screen size is almost same as old version(around 0.5mm smaller for both sides) also FPC is bendable, so this design should be compatible to most old screen enclosure.

Finally, here is its photo:

Default VoCore2 only has one ethernet enabled, it is ethernet port0. But actually VoCore2 has 5 ethernet ports. This blog is talking about how to enable them.

First, let’s check the hardware connection.

One RJ45 with transformer and one 100nF are enough to make one ethernet port work.

Second, we need to enable ports in kernel level.

This is controlled by register 0x1000003c. In client mode, we can simply use “mem 0x1000003c 0xe001ff” to setup it, or you can use hard way to enable this by device tree.

Once you finish second step, when you plug in or plug out the ethernet cable, you will find a kernel log like “rt3050-esw 10110000.esw: link changed 0x00”;

Port0 plug in: “rt3050-esw 10110000.esw: link changed 0x01”;

Both Port0 and Port2 plug in: “rt3050-esw 10110000.esw: link changed 0x05”

PS: once you enable more than one ethernet, debug port UART2 will be disabled, you will need to change it to UART0/UART1 in VOCORE2.dtsi/VOCORE2.dts; also SDMMC port for SD card is disabled either, please check blog http://vonger.cn/?p=14701 and http://vonger.cn/?p=14435 for tutorial about using 5 ethernet ports and SD card same time.

Third, we need to setup in OpenWrt to enable them

I am not very good at this part, looks like default OpenWrt setting is enabled that two ports, Port0 and Port2, but actually we only have one ethernet by default hardware(VoCore2 Ultimate). So if you only need to use two ports and the ports happens to be Port0 and Port2, you do not need change anything.

If you need to use other ethernet port like ethernet port1, port3, port4, you will need to setup /etc/config/network. Maybe also need to enable them in device tree. This part I am still learning, now I am trying different connection to understand virtual lan, later I will write another blog talk about my learning process. Any suggestions are warm welcome, please email to me(a)vonger.cn or support(a)vocore.io.

When I make a test jig for a project, I need to write new uboot to cover old one. Normally I will use uboot UART to update uboot partition, that is the fastest way, we do not have to wait Linux system ready, but it has a failure rate because UART is not very stable.

Currently I need to login to Linux and run test application. I do not have to upload from UART anymore, but same time, I just found u-boot partition is default read-only. This is locked in VOCORE2.dts at compile stage to avoid user erase uboot by mistake. If we need to overwrite u-boot, we can not modify it directly but have to upgrade the firmware who has a writeable u-boot partition.

If I upgrade the firmware, it will take too much time, at least 2 minutes…not acceptable for mass production. For that reason, I am thinking, is that possible we hack the kernel and remove the READ-ONLY tag from mtd partition without do change to firmware?

Lucky, that is possible, and pretty simple to do.

mtd driver has a structure named mtd_info to store every detail of a mtd partition. It is using a flag named MTD_WRITEABLE to determine whether a mtd partition is readonly or not.

Reference: linux-4.14/drivers/mtd/ofpart.c

	if (of_get_property(pp, "read-only", &len))
		parts[i].mask_flags |= MTD_WRITEABLE;

Now, just need to find a way add that MTD_WRITEABLE flag to mtd partition.

We can not do it in user mode, because kernel mode memory is protected. So I write a small driver for it.

#include <linux/init.h>
#include <linux/module.h>
#include <linux/mtd/mtd.h>

int w2uboot_init(void)
{
    struct mtd_info *mtd;
    
    mtd = get_mtd_device_nm("u-boot");
    mtd->flags |= MTD_WRITEABLE;
    
    printk(KERN_INFO "unlock u-boot, now it is writeable\n");
    return 0;
}

void w2uboot_exit(void)
{
}

module_init(w2uboot_init);
module_exit(w2uboot_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Qin Wei");

Compile and insert this module to kernel. Magically, the u-boot is unlocked. Now we can use mtd -e u-boot write uboot.bin u-boot write to uboot partition.

To compile the code(save as w2uboot.c), try this way in same folder:

echo 'obj-m=w2uboot.o' > Makefile
make -C [path to linux]/linux-4.14.195 M=$(PWD) CROSS_COMPILE=mipsel-openwrt-linux- ARCH=mips

Recently a lot of chip shortage, really makes me headache. 🙂

This is a bluetooth module works with VoCore2, it is based on CSR8510.

PS: Qualcomm is really a suck company. I can not get any documentation from them but have to find some leak ones online…

Lucky thing, this CSR8510 is almost working out of box. No idea what that EEPROM used to do, I just use an empty EEPROM, this device still work normally.

So connect it to VoCore2 USB host port, then remember install bluez-daemon in VoCore2, it just works.

We can use hciconfig / hciconfig hci0 to show this device.

And to make it work, call hciconfig hci0 up

Or scan nearby device by hcitool scan

Or ping the nearby device to make sure everything is normal: l2ping xx:xx:xx:C1:58:C2

Finally. here it is 🙂

Finally my patch has into main branch of mt76 🙂 now we have stable official supported wireless driver, and ADHOC, MESH are default supported too.

My patch link is here: https://github.com/openwrt/mt76/pull/426

Thanks the admin, make it in better format: https://github.com/openwrt/mt76/commit/97e65131440ccae916e76323251b80cafdfc9006

Next blog, I will try mesh and adhoc mode, check if they work.