[CC1352P Review] The beginning of a little frustration[Copy link]
This post was last edited by cruelfox on 2019-6-3 10:20 I just finished the review of STM32WB55, and I want to "strike while the iron is hot" to continue to review CC1532P1-LAUNCHXL. Both of them are systems with M4 main core + M0 wireless dedicated core, which can be used as a reference. However, I have played with ST's MCU for several years, and I have never played with TI. I started playing with MCU with ATMEL's C51, and the AVR stage lasted for a long time. Later, I came into contact with ARM with NXP's ARM7TDMI, and then I got to know ST... I have also used NXP and ATMEL's Cortex-m series, but I am not as familiar with them as STM32. As for TI's MCU, I bought the MSP430 Launchpad a long time ago, but I haven't programmed a single program... I don't dislike TI, I bought a board but haven't played with it, and there is also Microchip's PIC series, I really don't have enough time (lan). This time I applied for the evaluation, so I put some pressure on myself. I did some research before applying and confirmed that the documentation of the development program was complete. The problem I expected to encounter was the development environment: TI's CCS, the computer I usually use cannot install the new version because... XP system. I have installed CCS 6, which may not support CC1352. Fortunately, Simplelink CC13x2 CC26x2 SDK can still be installed under XP. As long as the SDK source code is available, it is still easy to deal with, because CCS supports GCC. In theory, you can use GCC yourself, but it takes some effort. Each of the SDK examples also has a makefile file, which makes it easier to port, and it is easier to handle than SW4STM32. I received two boards sent by the forum, and first connected them to the computer to install the driver. The debugger on this board is much more complicated than the usual one. According to @littleshrimp, this is because it has a power consumption measurement circuit, not just a debugger. The debugger is called XDS110. According to the introduction on the TI website, I downloaded emupack 8.1.0, which contains the necessary drivers. XP support has not encountered any problems so far (there will be some later). If the compilation problem can be solved manually without installing CCS (v7 does not support XP, v9 does not support 32-bit Windows), there are still two problems that must be solved - Flash download and GDB debugging. For STM32, I have always used the ST-Link utility command line tool to download. TI has a CCS UniFlash software, which is equivalent in function, but its last version that supports XP: 3.4.1 does not support CC1352 (it is written to support CC13xx, but there was no 1352 at that time). Should I use the one that comes with the board or other tools to download it? I checked the CC1352P1 datasheet and found that this chip does not support the SWD interface. XDS110 uses JTAG to connect it, and also supports two-wire cJTAG - but cJTAG is not SWD. I thought SWD was supported by all ARM Cortex-m series, but I was wrong. So I can't use other xxx-link to debug CC1352 through SWD, so I give up this way. According to the introduction, XDS110 is CMSIS-DAP compatible, so OpenOCD may be able to do it. But I used OpenOCD 0.9.0 on my computer, and selected CMSIS-DAP as the interface, but it didn't work: there was an inexplicable error, and I couldn't configure it as a JTAG interface. TI also provides an OpenOCD version that can support XDS110 - in source code form, but I don't have the ability to compile it into a usable program under Windows yet. OpenOCD 0.9 can't support it, so debugging is a problem. However, TI's emupack comes with a GDB server, so there is still a chance. The gdb_agent_console.exe in it can run under XP, and it needs a "board data file" to work, but there is no such file in the emupack directory. Searching for this problem on the Internet, the clue I got was: this file must be generated in CCS. So I still can't get around CCS. However, after generating it, it doesn't need to be regenerated every time. I have to find another computer and install a newer CCS. The reason why I mainly use XP is that the hardware is old (configuration from several years ago), and I really don’t like the huge and slow Windows 7 system. I used another brand laptop with Windows 7, installed CCS 8 series that is confirmed to support CC1352, and then installed simplelink SDK. CCS runs really slowly... As a test, I first imported a project from the SDK to compile it. I selected the GCC versions of the two projects rfEasyLinkRx and rfEasyLinkTx based on ti-rtos. After CCS imported them, there will be an additional tirtos_builds_CC1352P1_LAUNCHXL_release_gcc project. After selecting "Build project", CCS started working. After a while, the progress increased very slowly. In the console below, many identical lines appeared: making package.mak (because of ... xdc/bld/bld.js) I don't know what it is doing behind the scenes... Why is it so slow? I left it aside to do something else. After an hour and a half, it was still not finished. The progress was very slow to more than 60%. I couldn't stand it anymore and forced it to stop. Considering that there are pitfalls in the compilation of tirtos, I will go around and find an example that does not use RTOS to try. I simply don't need the wireless function and select the pwmled2 project under drivers. After importing it into CCS, the compilation was completed quickly and smoothly. Select Debug on the CCS menu, but an error was encountered. It was Energytrace or something... Do I need to install the energytrace package to debug? It doesn't make sense. I'd better find a way to burn it to the board first. I am not familiar with eclipse and don't know how to burn separately in CCS, so I looked for TI's download tool. SmartRF Flash Programmer-2 supports CC1352. I installed it and tried it. It can read the flash content, so I used it to burn. This program can directly read ELF format files and burn them without converting to HEX. After the burning is successful, the LED on the board does not respond... I have to find a way to debug it, but the CCS debug cannot be started. Let's go back to the GDB solution and find the "board data file" required by gdb_agent_console. According to the search clues, it is in the options of the CCS project, and the default is "auto generate", but I can't find it in the project directory.dat file. Later, I finally found this file in the subdirectory of Local settings\Application data in the Windows user directory. It is a temporary file of the software! Then, I returned to my XP machine and finally started the GDB server with gdb_agent_console. I accessed it with gdb and found that the CPU entered an infinite loop. What is the reason? I copied the compiled ELF and let gdb load it. I found that it stopped in a ThisLibraryIsFor_CC13x2_CC26x2_HwRev20AndLater_HaltIfViolated() function. Does the chip version and SDK not match? I looked at the label on the back of the board and it was SDK 2.10. I have to download an older SDK and try again another day.
I just tried it and I didn't encounter this problem with ccs, but it's also very inconvenient for me to use ccs. As you said, it can be very slow sometimes. If it doesn't work, you can try iar.
This post was last edited by Daqin Zhengsheng on 2019-6-3 11:08 The main frequency of this chip is not too high, otherwise it would be very good for making drones!
SDK and chip version matching problem: I downloaded two other SDKs and found that in Simplelink cc13x2 SDK 2.30, there are two directories, cc13x2_cc26x2_v1 and cc13x2_cc26x2_v2, under the source/ti/devices directory. I will try this one and it is expected to work.
提升卡
变色卡
千斤顶
How can I change the hardware? I might as well mess with Linux.