Adventures with a STC89C52 development board

Some months ago I came across an offer of 10 STC15F104W for about 30¢ each so I took the plunge. These are 1T 8051 MCUs with 4kB flash and 128B RAM. The only drawback is it is a DIP-8 or SOP-8 device so has only 6 I/O pins but this may be sufficient for small applications, and you can always extend the I/O with serial protocols.

The datasheet was easily found with a search and In System Programming only requires Tx/Rx pins, readily available from a USB to TTL converter. But being a lazy person I wondered if I could use my QX-mini51 development board since it already has the converter on board and I have already set up stcgal.

Looking at the pinout, besides the power pins, the 6 I/O pins are port 3.0 through 3.5 with P3.0 and P3.1 used for serial communications. I just needed an adaptor. I had some prototyping boards of the right size, so I soldered a DIP-8 socket and then wires to 8 pins taken from a broken precision (round pin) IC socket. I'm feeling chuffed about not throwing that away. I don't really need P3.2 to P3.5 but I wired them anyway. I soldered another pin at 21 for better registration. Here's the result:

BTW the datasheet suggests isolation diode and resistor to prevent powering the MCU from the USB serial adaptor. This is not necessary since there is only one power supply, that feeding the QX-mini51.

I connected up the board to the USB port, ran stcgal, pressed the power switch and got this:

$ stcgal 
Waiting for MCU, please cycle power: done
Protocol detected: stc15
Target model:
  Name: STC15F104W
  Magic: F294
  Code flash: 4.0 KB
  EEPROM flash: 1.0 KB
Target frequency: 0.000 MHz
Target BSL version: 7.2.5Q
Target wakeup frequency: 35.650 KHz
Target options:
  reset_pin_enabled=False
  clock_source=internal
  clock_gain=high
  watchdog_por_enabled=False
  watchdog_stop_idle=True
  watchdog_prescale=64
  low_voltage_reset=False
  low_voltage_threshold=3
  eeprom_lvd_inhibit=False
  eeprom_erase_enabled=True
  bsl_pindetect_enabled=False
  por_reset_delay=long
  rstout_por_state=high
  uart2_passthrough=False
  uart2_pin_mode=normal
  cpu_core_voltage=unknown
Disconnected!

If you're wondering why the target frequency is 0, this MCU family has an onboard oscillator.

Update after 2½ years

I finally got around to writing firmware for a project using these tiny form factor MCUs which I will post about in due course. However when I tried to flash the firmware on the MCU, I ran into some glitches which I am pleased to say I solved.

1. A silly error on my part. I couldn't connect with the QX board until I realised that because I had an Arduino Uno plugged in, the QX board was allocated /dev/ttyUSB1 instead of the /dev/ttyUSB0 I wrote in my Makefile.
2. I got my workstation talking to the MCU, but got this error message.

   Protocol error: uncalibrated, please provide a trim value

   A search took me to this issue in the stcgal project: https://github.com/grigorig/stcgal/issues/96 Simply put I have to provide an operating frequency for the MCU. This also answered my question about what frequency the timers would run at, which is important for timing in the firmware. I chose a trim frequency of 11059 (kHz) as it will match that of the STC89C52 normally on the QX. Although the STC15W goes to 35 MHz, speed is not important.

3. Next I encountered this error message:

   Protocol error: incorrect frame start

   This took me to this issue: https://github.com/grigorig/stcgal/issues/17 It's quite a long thread but to cut to the chase, I needed to update my stcgal version, which simply required:

   git pull
   ./setup.py build
   sudo ./setup.py install

   It still wouldn't program at the default 115200 baud, but when I dropped to 38400 baud, it worked fine.

Just to mention that while the plugin crystal allows for a different one to be swapped in, contact can be sometimes erratic, causing the program to halt. Wiggling the crystal a little gets the program to restart. Fortunately I'm only using the dev board to prototype a circuit and will later have a PCB with a soldered-in crystal for a project.

I have added a clock firmware project prototyped using this dev board and a DS3231 RTC board to Github. Details are sparse because I intend to build a board for it, make it a project in its own right, and take it futther in due course, but it should be possible to work out what goes where from the program.

10 STC89C52s that I bought for under a dollar each have finally arrived after braving the stormy seas, well empty skies, of this COVID-19 era. I put them on the dev board and tested with the usual blinky program. They didn't require the newer 7.2C download protocol in stcgal like the one that came with the board, so they were old stock. I'll be using the dev board to check my firmware for future projects, and I'll mark this project completed.

I have published the QX-mini51 sample programs, converted to compile with SDCC instead of Keil, at a new Github repo, see the list of repos referenced by this project. They are fairly basic but demonstrate how to handle peripherals on the MCS51 architecture. I have also included some code::blocks project files if you want to use an IDE to develop. I'd be interested to hear from people using that. I only read about it and installed it recently.

Have a lot of fun.

The comments in the programs for the Keil compiler are in Chinese so I ran them through a translator and then added them to the Github repo as parallel files. The translator inserted spaces in some places so they will provoke syntax errors if you try to compile them, so don't do that. They are only for reading the comments. Some are relevant such as notes that a jumper must be disconnected for a particular experiment. For example the port driving the LEDs is also used for input in some experiments so the LEDs need to be disconnected for those. Some comments explain the calculations behind time-critical delays.

I will transfer the relevant comments to the SDCC versions which I'll be testing soon.

I also found a higher resolution version of the schematic which should be easier to read.

After having converted 30 odd sample programs from Keil C to SDCC, here is a summary of the differences I encountered.

• Keil uses sbit to declare special bit registers using for example P0^7 to refer to port 0 bit 7. SDCC uses __sbit and a different syntax. But since most of the special registers are defined in SDCC includes, usually it suffices define your symbol to be the same as say P0_7.
• Putting large constants, e.g. tables, in the RO code area in Keil is done with the qualifier code after the type declaration, e.g. uchar code table{] = …. In SDCC it's declared thus: __code uchar table[] = ….
• Keil uses for example: interrupt 1 using 1 to qualify an interrupt service routine (ISR) as hooking to interrupt vector 1 and using register bank 1. SDCC uses the syntax: __interrupt(1) __using(1). Note that Keil makes interrupt and using unavailable for symbols. Ditto for sbit and code. Oh and remember that in SDCC the ISRs (or at least a prototype) must appear in the file containing main() or the vectors won't get initialised. This wasn't an issue for the sample programs as each was in a single C file.
• Keil has a data type called bit, usually used for booleans. I didn't see any advantage so I converted those to char (which is actually uchar for the 8051 architecture).
• The standard include in Keil C appears to be reg52.h. In SDCC it's 8051.h. Keil has additional includes like intrins.h and math.h, but these are not needed for SDCC. stdlib.h should be included if you use abs() with SDCC. stdio.h should be included if you use printf and the ilk for the serial port, and in the case of SDCC you need to implement int putchar(int) whereas it's supplied in the Keil library. If you have a MCU with more special registers then you should include the definitions for those. You may need to create your own if somebody hasn't done it already.
• Keil appears to define a special function called _nop_(). For SDCC just #define that to __asm__("nop").
• Not really a compiler difference but since Keil runs on a case insensitive OS, you can get away with #include <reg52.H> but you must respect the filename case on Linux.
• Again not a compiler difference but the sample programs often used defines like #define uchar unsigned char. I prefer to use typedefs.
• Keil lets you get away with a mix of old style and new style function headers, like int fun(int a,b), whereas you should use the standard int fun(int a, int b) in SDCC.
• In one initialisation of a structure, Keil let the programmer get away with not properly nesting braces for a struct element. It was something like this:

struct fontentry {
    uchar[3];
    uchar[16];
} f = { "AB", 0x00, 0x01, … };

 The initialisers for the second uchar array needs to be surrounded by braces according to the standard.

If I remember any other differences I'll edit this log.

The sample programs in the repository that have been published on Github have comments in Chinese. However the encoding was GBK which was why they weren't displayed as Chinese characters but as octal codes or weird characters. Using iconv, I've converted those to UTF-8. So even if you can't read them, at least you can put them through a translator.

Actually I discovered this after I had finished creating a parallel Github repository for compilation with SDCC instead of Keil as in the originals. So after testing the programs, I will translate some key comments and reinsert those into the programs. Stay tuned.