The VC series includes two modules and their corresponding development boards, with the development board's factory firmware being different from the module's factory firmware.
1. Communication Interface Connection
If using the module for serial port connection, it is recommended to use the following interfaces for communication: RX1, TX1.
If using the development board, simply use the USB port for debugging.
Here is a schematic of how to connect the module with a MCU or TTL module:
UART1 Default Serial Port Configuration:
- Baud Rate: 115200
- Data Bits: 8
- Stop Bits: 1
- Parity: None
- Flow Control: None
UART0 (TX0:IOB8) Log Output Configuration:
- Baud Rate: 57600
- Data Bits: 8
- Stop Bits: 1
- Parity: None
- Flow Control: None
2. Development Board Hardware Description
VC-01 and VC-02 share a development board:
3. Firmware Burning Instructions
The VC series has two firmware burning methods:
JTAG Debugger Burning:
This method uses a dedicated JTAG debugger to burn the complete firmware, using the
software UniOneDownloadTool.exe, with firmware files typically named
uni_app_release.bin.
Serial Port Burning:
This method uses a TTL module for firmware upgrades, with no specific requirements for the
module, using the software UniOneUpdateTool.exe, with firmware files typically named
uni_app_release_update.bin.
Details for both burning methods will be introduced below.
(1) JTAG Burning Connection and Introduction:
JTAG burning can only be done with a dedicated JTAG debugger and does not support debuggers like J-link.
The JTAG debugger is connected to the VC series as follows:
After connecting the JTAG debugger to the VC series as shown, insert the debugger into the computer (the debugger requires driver installation;
for installation instructions, see:
Hummingbird-M-Production-Tool/M_Download_Tool_User_Guide.pdf),
and open UniOneDownloadTool.exe.
Burning Process:
(2) UART Serial Port Upgrade Connection and Burning Introduction:
The wiring for serial port burning is the same as for communication wiring, with no special precautions. The most important thing is the firmware requirements for burning:
- The firmware for burning must be generated using the build.sh update command as uni_app_release_update.bin.
- The burning tool must be UniOneUpdateTool.exe.
The delay burning process begins below.
Note: All port numbers will have a yellow background when successfully opened.
II. Factory Firmware Usage of Modules1. Command Words and Command Codes
The factory firmware of the module has default written-in common commands and their corresponding command codes.
2. Command Code Explanation
Each command code represents the unique command recognized by VC. For example, the meaning of "0x5a 0x00 0x00 0x00 0x5a":
Start Bit: Fixed value: 0x5a
Command Number: Represents the unique command: 0x00 for wake word number
Reserved Bit 1: Fixed value: 0x00
Reserved Bit 2: Fixed value: 0x00
Check Bit: XOR of the first four bits, e.g., 0x5a XOR 0x00 XOR 0x00 XOR 0x00 = 0x5aIII. Factory Firmware Usage of Development Boards
The factory firmware of the development board has the same command words as the module, with the addition of LED control functions and button wake-up functions.
The factory firmware already includes excellent commands, and the microcontroller can process them based on the corresponding command codes. The most important byte of the command code is the check bit, which can be calculated in C as follows:
1. // Suppose to judge wake-up: 0x5a 0x00 0x00 0x00 0x5a
2. char start_bit=0x5a;
3. char cmd_num_bit=0x00;
4. char temp_num1_bit=0x00;
5. char temp_num2_bit=0x00;
6. // Calculate check bit
7. char check_bit=start_bit^cmd_num_bit^temp_num1_bit^temp_num2_bit;
The most important question comes, does it support secondary development? In fact, this article has already made it very clear:
The burned firmware must be uni_app_release_update.bin generated using the build.shupdate command.
Comments