As I’ve discussed the debugger for the W806 microcontroller, let’s now have a look at the microcontroller itself. Apart from the W806, it seems there is also the W801 on sale. These goes for cheaper then the W806, and appear to be the W806 with added 2.4 GHz radio, providing IEEE802.11b/g/n (aka WiFi 1/2/4) and BLE 4.2. Otherwise, on first glance (the datasheets are Chinese) they appear to be the same. As these W801 boards are sold for cheaper then the W806 boards, I’ve ordered some of those.

However, I have not been able to connect to them, either over serial or using the CK-Link Lite. It seems, the microcontroller is being kept in reset. Did they put a pull down on the reset line in stead of a pullup? As when I pull the reset up to 3.3 volts, for which I need a 680 Ohm resistor, as a higher value will give a too low voltage, as there appears to be a pull down resistor on there. For now, let’s concentrate on the W806.

So, the WinnerMicro W806 Microcontroller, based on the C-SKY V2 architecture. For this architecture, we have upstreamed binutils and gcc support, so, despite being an uncommon architecture, software support is available. Furthermore, I’ve established debugger support. We can find the SDK For this microcontroller at https://github.com/IOsetting/wm-sdk-w806. Note that, the debugger does not appear to support flashing at this moment. To upload we need to use the serial connection. The said SDK includes the upload tool, in source form, so everything we need is available.

The SDK is a Makefile project. The source files and the application files are designed to go into the project. One would create a fresh copy of the SDK, and write the application in it. I’m not sure how they intended for the demos to work. Am I supposed to copy the desired demo into the app directory? Oh well…

I’ll try to make it build using my own “ucdev” makefiles. Adding support for the architecture, this means, setting the compiler prefix and compiler flags, and we are good. Creating a Makefile which adds the startup and driver files, copy the linker script, and there we go, we get a binary. However, first run, it crashes. Turns out, I needed to patch the linker file a bit:

    KEEP(*startup.o(.vectors))

Note is says startup.o. Now my “ucdev” Makefiles name this file startup.S.o, thus it would not link the vector table into the image. Furthermore, the same for this part

    KEEP(*startup.o(.vdata))

And then… it runs as expected.

Now, we can get code running, let’s have a look at the drivers provided. The API provided by the drivers in this SDK resemble the STM32 Cube HAL a lot. Therefore, it should be possible to port code written for an STM32 (and using the Cube HAL) with little effort. Some differences to note is the fact there are 16 pins on a GPIO PORT on an STM32, but there are 32 pins per GPIO PORT on the W80x. Just some little details. As such, I’ve been able to run some SPI code I’ve had running on an STM32 to run on the W806.

So far so good, it works. I think I’ll rewrite their linker script anyways. Apart from the patches I mentioned above, there are some other issues I’d like to address:

MEMORY
{
    I-SRAM : ORIGIN = 0x08010400 , LENGTH = 0xEFC00 /* I-SRAM  1MB */ 
    D-SRAM : ORIGIN = 0x20000100 , LENGTH = 0x47f00 /* D-SRAM  288KB */
    V-SRAM : ORIGIN = 0x20000000 , LENGTH = 0x100   /* off-chip SRAM 8MB */
}

What the hell is I-SRAM. According to the datasheet, that memory address is in FLASH. So, I’d like to rename them so something with more intuitive names. I wonder… Espressif also has some weird names regarding memory. Are they perhaps following some Chinese convention I am not aware of?