Found 1 MCU chip W801 W806 with very rich peripheral resources

[yfyungit]

Description

I think this chip has high development potential and value. If the mircopython community can support this MCU, it will be a good choice.

This chip currently supports the Arduino programming environment
https://github.com/board707/w80x_arduino

MCU official website : https://www.winnermicro.com/html/1/156/158/569.html

Chip appearance
QFN56 package, 6mm x 6mm
MCU features
Integrated 32-bit XT804 processor, operating frequency 240MHz, built-in DSP, floating-point unit and security engine
Built-in 2MB Flash, 288KB RAM Integrated PSRAM interface, supports up to 64MB external PSRAM memory
Integrated 6-way UART high-speed interface
Integrated 4-way 12-bit ADC, maximum sampling rate 1KHz
Integrated 1 high-speed SPI interface, supports up to 50MHz
Integrated 1 master/slave SPI interface
Integrated 1 SDIO_HOST interface, supports SDIO2.0, SDHC, MMC4.2
Integrated 1 SDIO_DEVICE, supports SDIO2.0, maximum throughput 200Mbps
Integrated PSRAM expansion interface, supports up to 64Mbyte
Integrated 1 I2C controller
Integrated GPIO controller, supports up to 44 GPIOs
Integrated 5-way PWM interface
Integrated 1 Duplex I2S controller
Integrated LCD controller, supports 4x32 interface
Integrated 1 7816 interface
Integrated 15 Touch Sensors
Security features
MCU has built-in Tee security engine, the code can distinguish between secure world/non-secure world
Integrated SASC/TIPC, memory and internal modules/interfaces can configure security attributes to prevent non-secure code access
Enable firmware signature mechanism to achieve secure Boot/upgrade
With firmware encryption function to enhance code security
Firmware encryption keys are distributed using asymmetric algorithms to enhance key security
Hardware encryption module: RC4, AES128, DES/3DES, SHA1/MD5, CRC32, 2048 RSA, true random number generator
Wi-Fi features
Support GB15629.11-2006, IEEE802.11 b/g/n
Support Wi-Fi WMM/WMM-PS/WPA/WPA2/WPS
Support EDCA channel access method
Support 20/40M bandwidth working mode
Support STBC, GreenField, Short-GI, support reverse transmission
Support AMPDU, AMSDU
Support IEEE802.11n MCS 0~7, MCS32 physical layer transmission rate gear, the maximum transmission rate is 150Mbps
Support Short Preamble when sending at 2/5.5/11Mbps rate
Support HT-immediate Compressed Block Ack, Normal Ack, No Ack response mode
Support CTS to self
Support Station, Soft-AP, Soft-AP/Station functions
Bluetooth features
Integrated Bluetooth baseband processor/protocol processor, support BT/BLE dual-mode working mode, support BT/BLE4.2 protocol
Support Bluetooth network configuration
Low power mode
3.3V single power supply
Support Wi-Fi energy-saving mode power consumption management
Support working, sleeping, standby, and shutdown working modes
Standby power consumption is less than 10uA

Code Size

No response

Implementation

I hope the MicroPython maintainers or community will implement this feature

Code of Conduct

Yes, I agree

[robert-hh]

Support for new devices is usually driven by the community. The maintainers have their primary focus on the MicroPython core mechanisms. So If you like to support this device, start working. Usually a condition for a device to be integrated into the core set of devices it needs good and continuing support by the MCU manufacturing company, someone supporting the port and a good offering of boards with that MCU. Besides the ports listed on the web site there are quiet a few port for other devices made by board vendors (e.g. XBEE) of people from the community. Personally I maintain together with others a port for the W60x device, the predecessor of the W80x (https://github.com/robert-hh/micropython/tree/w60x and https://github.com/robert-hh/Shared-Stuff/tree/master/w600_firmware). I had a short glance at the W80x a while ago bit decided not to start an implementation. Do you know if English support documentation for the MCU and the library is available from the vendor?

[yfyungit]

@robert-hh The chip supplier is in China, and I also live in China, so I can easily assist in obtaining relevant data files. If necessary, I can also assist in obtaining the circuit board used in the development of the device.

[robert-hh]

@yfyungit Thank you for the link to the w80x data sheet. I have already a translated document about the w80x registers and have two links to web sites with information: https://github.com/cjacker/wm_sdk_w80x and http://zone.winnermicro.net:60800/w800/en/latest/get_started/hlk-w800.html. The latter now requires authentication which it did not the last time I visited it.
Maybe it is the same that you are referring to.

[yfyungit]

The following is the latest test version of the SDK I obtained. They are expected to release the official version of the new generation SDK this month. The SDK contains detailed English API instructions. Due to the size limit of GitHub files, I split the SDK files into volumes and compressed them into ZIP files before uploading them. After downloading, you need to rename the file names in the following order before you can decompress them:

wm_iot_sdk_v2.2-beta-86box.zip.001
wm_iot_sdk_v2.2-beta-86box.zip.002
wm_iot_sdk_v2.2-beta-86box.zip.003
wm_iot_sdk_v2.2-beta-86box.zip.004
wm_iot_sdk_v2.2-beta-86box.zip.005

---

wm_iot_sdk_v2.2-beta-86box.zip.001.zip
wm_iot_sdk_v2.2-beta-86box.zip.002.zip
wm_iot_sdk_v2.2-beta-86box.zip.003.zip
wm_iot_sdk_v2.2-beta-86box.zip.004.zip
wm_iot_sdk_v2.2-beta-86box.zip.005.zip

[rkompass]

The registers of the w80x are almost exactly the same as those of the w60x and the older SDK also was almost an exact copy of the SDK of the w60x.
I had the idea to try to start with the REPL only version of MP.
To make things more simple: How do I get a REPL only version of the w60x? I refer to a minimal sources version. Not the present port with every feature deactivated.
There should be a good chance that this compiled with the older w80x SDK could just run.

[rkompass]

Also a nice reference (for older SDK) might be https://www.elektroda.com/rtvforum/topic3905652.html.

[robert-hh]

Or the doc files in https://github.com/cjacker/wm_sdk_w80x/tree/main

[jonnor]

Btw, it is possible to use MicroPython inside any C/C++ program by using the "embed" port. This is the easiest way to get MicroPython up and running on a device, and one can then lean on existing high-level SDKs such as Arduino. One will be able to load and execute MicroPython code/modules. However more would be needed to get the various hardware exposed via machine module, and to get things like filesystem, mpremote etc.

[rkompass]

In an attempt to start development for the w800 I followed instructions in [https://github.com/cjacker/wm_sdk_w80x/tree/main](in https://github.com/cjacker/wm_sdk_w80x/tree/main).
All went through nicely until I attempted to flash the device:

$ make flash
make[1]: Verzeichnis „/home/raul/csky/wm_sdk_w80x/app“ wird betreten
make[1]: Verzeichnis „/home/raul/csky/wm_sdk_w80x/app“ wird verlassen
make[1]: Verzeichnis „/home/raul/csky/wm_sdk_w80x/demo“ wird betreten
make[2]: Verzeichnis „/home/raul/csky/wm_sdk_w80x/demo/console“ wird betreten
make[2]: Verzeichnis „/home/raul/csky/wm_sdk_w80x/demo/console“ wird verlassen
make[1]: Verzeichnis „/home/raul/csky/wm_sdk_w80x/demo“ wird verlassen
LINK     w800.elf
OBJCOPY  w800.bin
generate normal image completed.
generate normal image completed.
compress binary completed.
generate compressed image completed.
build finished!
connecting serial...
can not open serial
make: *** [tools/w800/rules.mk:158: flash] Fehler 255

I already tried sudo chmod 666 /dev/ttyUSB0 and this device now can be written and read by everything. But this did not help.
The serial connection has to be established before starting to sync and checking the characters sent by the bootloader of the w800 (w801 actually) for starting the download.
So the actual device now should not have an impact, but who knows?

This problem of not being able to open /dev/ttyUSB0 somehow sounds familiar. But ATM I have no idea how to solve it.
Perhaps in the next days I will compare the wm_tool of the w600 which worked, with that of the w800. My guess is that they differ just by some special character sequence which is there for preventing use with a wrong device.

In case someone had success in solving/circumventing the above problem I would be eager to learn how.

[yfyungit]

You can try to use the SecureCRT tool to burn the firmware to see if it can be burned in normally send xmodem
https://www.vandyke.com/products/securecrt/
https://www.winnermicro.com/upload/1/editor/1621128561219.pdf

[yfyungit]

When w800 is in boot mode and the serial port is at 115200 baud rate, you should receive the ccc character

[rkompass]

Thank you.
Interestingly I managed to erase flash and download an image with the w600tool by @vshymanskyy.
Afterwards the CCCC sequence was there..
Still I will try to find out what's wrong with the wm_tool included in (and compiled by) the SDK.

[rkompass]

The board I have is this w801 board:

It has a slightly special feature that is here (translation from chinese) described as:

The W801 development board has some differences in downloading compared to the W806. Since the W801 has built-in serial port RTS control, some corresponding phenomena are observed:

• After the W801 development board is connected to the USB, it will start running the program burned into the chip normally.
• When using Putty, XShell, Cutecom, Minicom and other serial port programs to connect to the W801 development board, the operation will be suspended immediately. When using Lianshengde Upgrade Tools, XCOM and other software, it will not. After inspection, the difference lies in whether RTS is pulled low. RTS must be in a high level state during normal operation.
• When the serial port pulls RTS low, the W801 development board is actually reset. If it is not pulled high, it will remain in a stopped state. If it is pulled high, it will reset and restart.
• After the serial port programs such as Cutecom and Minicom are disconnected, RTS returns to high level and the W801 development board will reset and restart.

So this explains the difficulty to flash the board or connect it to a serial under Linux.
It was suggested to attach a 4.7 µF ceramic capacitor between the Reset and GND pins as demonstrated in this video.
But we don't have to as there is the w600tool.
With the python script given in the chinese website you can observe the CCCC - sequence in boot mode and the code demonstrates that setting RTS to high is necessary to get into that. Obviously the w600tool does that already.

From the above linked video I took the kind of blink program (slightly corrected) and here it is:

#include "wm_include.h"

char pins[7] = {WM_IO_PB_05, WM_IO_PB_25, WM_IO_PB_26, WM_IO_PB_18, WM_IO_PB_17, WM_IO_PB_16, WM_IO_PB_11};

void UserMain(void)
{
	for(int i = 0; i < 7; i++) {                    // initialize the GPIOs of the 7 LEDs
		tls_gpio_cfg(pins[i], WM_GPIO_DIR_OUTPUT, WM_GPIO_ATTR_FLOATING);
		tls_gpio_write(pins[i], 1);
	}
	while(1)
	{
		for(int i=0; i<7; i++)
		{
			tls_gpio_write(pins[i], 0);
			tls_os_time_delay(200);                // wait 200 system ticks which is 200 ms
			tls_gpio_write(pins[i], 1);
		}
	}
}

This can replace the app/main.c in the wm_sdk_80x and it's built with a make.

Voila, a running LED light.