【CC1352P Review】What is a Sensor controller?

cruelfox

【CC1352P Review】What is a Sensor controller? [Copy link]

　　CC1352 contains a sensor controller. In the introduction, it is only described as a separate low-power processor equipped with several peripherals for analog acquisition and external communication in low-power operation. It can run independently from the main system, and of course the power consumption must be lower than that of the M4 main CPU to be cost-effective.

However, the sensor controller is not an ARM core, it is a 16-bit CPU core, but it is not MSP430. The CC1352 reference manual has a detailed description of its core registers and instruction set. It can be seen that in order to save power, the function of this CPU is not strong.
　　In terms of bus connection, the sensor controller belongs to the AUX domain. This is a subsystem. In addition to the CPU, there are some separate hardware devices. These devices can be accessed by the M4 main CPU through the bus bridge, but not vice versa.
The instructions and data of the sensor controller are stored in a 4kB SRAM . Therefore, it must be initialized by the main CPU and the code must be loaded into this SRAM before it can work.

　　The sensor controller requires a separate development tool: Sensor controller studio, which uses a programming language similar to C. After installing this software, I tried an LED blink example, but I couldn't find the compile menu. As a result, it compiled automatically and quickly. If the development board is connected to the computer, you can connect the board and run it, and you can debug and track the execution. Moreover, this process does not require CCS to participate.
　　I unplugged the board again and found that the program in the original flash was not affected. This shows that the program is directly written to the SRAM of the AUX domain by the debugger. So, what is generated by the compilation process?

　　There are only some source files in the output directory, no binary files. After checking, I found that these files are for the development of the main CPU (but not like the version with GCC support), which should be integrated into the application project.
　　In the code, there is this:

/// Firmware image to be uploaded to the AUX RAM
static const uint16_t pAuxRamImage[] = {
    /*0x0000*/ 0x140E, 0x0417, 0x140E, 0x0438, 0x140E, 0x0442, 0x140E, 0x045F, 0x140E, 0x0468, 0x140E, 0x0471, 0x140E, 0x047A, 0x8953, 0x9954, 
    /*0x0020*/ 0x8D29, 0xBEFD, 0x4553, 0x2554, 0xAEFE, 0x445C, 0xADB7, 0x745B, 0x545B, 0x7000, 0x7CA2, 0x68AB, 0x009F, 0x1431, 0x68AC, 0x00A0, 
    /*0x0040*/ 0x1431, 0x68AD, 0x00A1, 0x1431, 0x78A2, 0xF801, 0xFA01, 0xBEF2, 0x78A9, 0x68AB, 0xFD0E, 0x68AD, 0xED92, 0xFD06, 0x7CA9, 0x6440, 

　　That is, the Sensor controller studio writes the compilation results here, and the C program itself loads them into the SRAM for execution. This method is also the best choice. For example, (1) the program development of this 16-bit CPU has nothing to do with the ARM tool chain, it cannot access other devices on the chip, does not require the CC1352 SDK, and the development environment is independent of the main system. (2) The code of the Sensor controller is less involved with the main system, which is suitable for separate development and compilation on both sides. (3) If the Sensor controller is regarded as a functionally customized hardware, you do not need to worry about its software implementation when developing the application.