Development Notes and FAQ_Rev1.0

中文

Document Revision History

Version	Date	Author	Reviewer	Changes
Rev1.0	2026-09-21	zlc		Updated document

1 Introduction

This document introduces important notes and common issues encountered during Open development and use of Lierda Eigencomm-platform Cat.1 modules. You can use this document as a reference handbook. During real customer project development, when a problem is encountered, refer to this document first to check whether the same or a similar solution exists, so you can solve problems quickly and improve development speed and troubleshooting efficiency. This is the initial version and will be continuously improved.

2 General Basics

2.1 Does OpenCPU require a specific factory firmware?

No. Any factory firmware works. Flashing the user program will not erase calibration data or other information (stored in independent partitions).

2.2 Are different module series compatible with each other under OpenCPU?

No. The internal pin connections differ between modules and series. The module model used during development must be exactly the same as the one used in mass production.

2.3 Does OpenCPU support AT commands?

Only a limited set of basic commands is supported, as follows:

+CGMR         Request manufacturer revision identification
+ECRST        System reboot
+ECFSINFO     Get file system information
+CGSN         Request product serial number
+ECPMUCFG     Set PMU sleep level
+ECIPR        Set AT serial port baud rate (not saved after power-off)
+ECTASKINFO   Display task information
+ECPCFG       Set platform configuration
+ECNETCFG     Configure network interface parameters
+ECNETDEVCTL  Set network interface data path
+CREG         Network registration
+CEREG        EPS network registration status
+CGPADDR      Show PDP address
+ECCFG        Get and set UE extended configuration
+CSQ          Get signal quality
+CPIN         Enter PIN
+ECFREQ       Set preferred frequency / lock frequency or cell
+ECBAND       Set band information
+ECICCID      Return SIM card ICCID
+COPS         PLMN selection
+CFUN         Set phone functionality level
+CIMI         Request IMSI
+ECSIMCFG     SIM configuration (sleep/detection)
+ECSTATUS     Return UE key parameter status

2.4 Related Configuration Modifications

config/default.ini contains some configuration parameters that you can modify. Note that you must perform an erase-configuration flash when flashing; otherwise the configuration changes will not take effect.

• faultAction: Reset after a dump occurs, or save the dump. Generally used for capturing software dumps. Must be set to 4 for mass-production software.

• logPortSel: Which port the module’s low-level log is output from. Defaults to the USB log port.

• usbVBUSModeEn / usbVBUSWkupPad: Used to enable the VBUS function. Configure the corresponding wakeup source according to the schematic.

• cfun: Default cfun function at power-on.

• AutoApn: Whether to enable the auto APN function. Recommended to enable this for modules shipped overseas.

• dataCont: Whether to enable data flow control.

• uart1At: Whether UART1 is initialized as an AT port.

• appLogPort: Application log output port. Defaults to the USB AT port.

2.5 What does AON mean?

Always-On Domain Pin. Ordinary IO pins lose power during sleep and cannot maintain their level output. The interfaces corresponding to AON can still maintain their level output or keep their function valid after the module enters sleep.

2.6 What do NI&NP mean in the pin multiplexing table?

If not configured by default after power-on, they are floating. Use software configuration to initialize these functions.

2.7 Continuous 30mA high current caused by failure to camp on the network

Testing shows that the standard firmware enables the forced network camping function (AT+ECCFG="EmergencyCamp",1), so it keeps searching for the network. After disabling this function (AT+ECCFG="EmergencyCamp",0), testing shows it enters an intermittent network-search state (it stops after about ten minutes and then searches again).

However, for OPEN applications, the usual approach to control power consumption is still to disable CFUN and enter sleep.

2.8 How to modify partitions

In the current SDK version, the app partition and FS partition are dynamically adjustable. Taking the F6D_A base package as an example, the file is located at components/basePkg/F6D_A/partition_info.txt.

Default APP partition size: 0x0CB000, FS partition size: 0x01D000. The build output is as follows:

Increase the APP partition by 100K. Modify the configuration file as follows:

After the modification, clean and rebuild. The build output is as follows:

Warning

Notes:

1. After a version enters mass production, modifying partitions will cause differential or full upgrades to fail. Therefore, confirm the partitions before mass production; they cannot be modified afterwards.

2. Modifications must be 4k-aligned.

3. The current full-upgrade scheme saves the APP image package to the file system for full upgrade. If the APP partition is too large for the FS to store the APP image, the full-upgrade function will fail.

3 FreeRTOS-Related Questions

3.1 How to create a task

Refer to the code in examples/demo/src/demo_os.c to create a task:

// Task 1 function
void vTask1(void *pvParameters) {

    liot_trace( "Task1 in");
    UINT32 uxBits;
    for (;;) {
        liot_trace( "Task1 1111Received event, starting task...");
        // Wait for event
        LiotOSStatus_t result = liot_rtos_flag_wait(xEventGroupHandle, TASK_1_EVENT, LIOT_FLAG_AND_CLEAR, &uxBits, LIOT_WAIT_FOREVER);
        if (0 == result)
        {
            if(uxBits & TASK_1_EVENT) {
                liot_trace( "Task1 Received event, starting task...");
                // Execute task
                // ...
            }
        }
    }
}

// Create task 1
liot_task_t task1_handle = NULL;
result = liot_rtos_task_create(&task1_handle, 1024, LIOT_APP_TASK_PRIORITY, "Task1", &vTask1, NULL);
if(result == 0)
{
    liot_trace("Task1 task create success %d", result);
}
else
{
    liot_trace("Task1 task create fail %d", result);
}

3.2 How to determine the stack size when creating a task

The task size is the runtime memory size. It is unrelated to the amount of code and only relates to local variables and call depth. Generally, allocating 2 KBytes is sufficient; adjust appropriately according to the total size of the variables defined in the task.

For more details, refer to: How to determine the stack size when using FreeRTOS - CSDN Blog

Example:

When you see the liot_httpc_perform interface return the error code LIOT_HTTPC_ERR_UNKNOWN, check the current task stack size. It is recommended to use the liot_rtos_task_get_stack_space interface to obtain the remaining stack space (multiply the result by 4 to get the remaining bytes). If it is 0, the stack has overflowed and the stack size needs to be adjusted. The recommended stack allocation is: if the actual maximum usage is A, set the stack size to A / 0.9.