This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2F: No .cinit.data.load compression with BLE5 simple_peripheral project

Part Number: CC2640R2F
Other Parts Discussed in Thread: SYSBIOS, CC2642R

I am trying to find some more space so that I can port an existing product that uses the CC2640R2 to the BLE5 stack and I have noticed that with the BLE 4.2 stack simple_peripheral example project when I build the project the .cinit.data.load section is compressed, but with the BLE5 stack simple_peripheral example project it is not. And I can't seem to persuade the linker to compress it (which will probably save me enough space!).

Here is what I get in the map file with the BLEStack simple_peripheral example project:

.cinit 0 000103b0 0000053c
000103b0 000003f3 (.cinit..data.load) [load image, compression = lzss]
000107a3 00000029 (.cinit..data:ti_sysbios_family_arm_m3_Hwi_Module__state__V.load) [load image, compression = lzss]
000107cc 00000021 (.cinit..data:ti_sysbios_knl_Task_Module__state__V.load) [load image, compression = lzss]
000107ed 0000001f (.cinit..data:ti_sysbios_BIOS_Module__state__V.load) [load image, compression = lzss]
0001080c 0000001d (.cinit..data:ti_sysbios_knl_Clock_Module__state__V.load) [load image, compression = lzss]
00010829 00000010 (.cinit..data:ti_sysbios_knl_Swi_Module__state__V.load) [load image, compression = lzss]
00010839 00000003 --HOLE-- [fill = 0]
0001083c 0000000c (__TI_handler_table)
00010848 0000000b (.cinit..data:ti_sysbios_family_arm_cc26xx_Timer_Module__state__V.load) [load image, compression = lzss]
00010853 00000005 --HOLE-- [fill = 0]
00010858 00000008 (.cinit..bss.load) [load image, compression = zero_init]
00010860 00000008 (.cinit..data:xdc_runtime_Memory_Module__state__V.load) [load image, compression = lzss]
00010868 00000007 (.cinit..data:ti_sysbios_family_arm_cc26xx_TimestampProvider_Module__state__V.load) [load image, compression = lzss]
0001086f 00000007 (.cinit..data:xdc_runtime_Startup_Module__state__V.load) [load image, compression = lzss]
00010876 00000007 (.cinit..data:xdc_runtime_System_Module__state__V.load) [load image, compression = lzss]
0001087d 00000006 (.cinit..data:xdc_runtime_Error_Module__state__V.load) [load image, compression = lzss]
00010883 00000001 --HOLE-- [fill = 0]
00010884 00000068 (__TI_cinit_table)

And here is what I get in the map file with the BLE5 stack simple_peripheral example project:

.cinit 0 000199b8 00000fec
000199b8 00000ea7 (.cinit..data.load) [load image]
0001a85f 00000029 (.cinit..data:ti_sysbios_family_arm_m3_Hwi_Module__state__V.load) [load image, compression = lzss]
0001a888 00000021 (.cinit..data:ti_sysbios_knl_Task_Module__state__V.load) [load image, compression = lzss]
0001a8a9 0000001f (.cinit..data:ti_sysbios_BIOS_Module__state__V.load) [load image, compression = lzss]
0001a8c8 0000001e (.cinit..data:ti_sysbios_knl_Clock_Module__state__V.load) [load image, compression = lzss]
0001a8e6 00000010 (.cinit..data:ti_sysbios_knl_Swi_Module__state__V.load) [load image, compression = lzss]
0001a8f6 00000002 --HOLE-- [fill = 0]
0001a8f8 0000000c (__TI_handler_table)
0001a904 0000000b (.cinit..data:ti_sysbios_family_arm_cc26xx_Timer_Module__state__V.load) [load image, compression = lzss]
0001a90f 00000001 --HOLE-- [fill = 0]
0001a910 00000008 (.cinit..bss.load) [load image, compression = zero_init]
0001a918 00000008 (.cinit..data:xdc_runtime_Memory_Module__state__V.load) [load image, compression = lzss]
0001a920 00000007 (.cinit..data:ti_sysbios_family_arm_cc26xx_TimestampProvider_Module__state__V.load) [load image, compression = lzss]
0001a927 00000007 (.cinit..data:xdc_runtime_Startup_Module__state__V.load) [load image, compression = lzss]
0001a92e 00000007 (.cinit..data:xdc_runtime_System_Module__state__V.load) [load image, compression = lzss]
0001a935 00000006 (.cinit..data:xdc_runtime_Error_Module__state__V.load) [load image, compression = lzss]
0001a93b 00000001 --HOLE-- [fill = 0]
0001a93c 00000068 (__TI_cinit_table)

Setting --cinit_compression=lzss in the linker settings does not change this.

This is with CCS 11.2.0.00007 and SimpleLink SDK CC2640R2 5.30.00.03. Compiler is ti-cgt-arm_20.2.5.LTS.

But I get the same results with CCS 9.3.0.00012 and SimpleLink SDK CC2640R2 3.40.00.10.

I can't understand why that section is compressed in one project and not in the other. Does anyone understand the linker well enough to explain this or offer a solution please?

  • Hi,

    I have the same observations as you. I will look into the question with my team. I may need assistance from the team responsible for the linker. It may take up to a week for getting back to you. Please bear with me.

    In the meantime, if not already done, you may want to review this piece of documentation.

    Best regards,

  • Hi Charles,

    As Clement, mentioned we were able to replicate this in the latest SDK. I am still looking into this and reaching out to relevant teams. In the meantime, have you been able to perform any further tests or modifications to the code? Any additional information may be helpful in resolving this issue as quick as possible. Were you able to look into the guide provided by Clement? That section of the User's Guide provides a few methods for reducing consumed space that may be helpful in overcoming this issue.

    Best Regards,

    Jan

  • Hi Jan and Clement,

    Thanks for your replies. The link that Clement sent was very useful and I have been able to remove enough modules to get the code to fit and have it running. In particular I removed the bond manager which I did not need.

    I also had to remove a custom module that is needed in the final product, so we are looking at using the CC2642R. But getting it running on the existing hardware is very useful as I can now do some testing with BLE5 and the coded phy.

    So I don't need the .cinit.data.load section compression issue solved for my work. But I am very curious to know why it is not compressed and I suspect it would be useful to some of your other customers to solve the issue.

    regards,

    Charles

  • Hi Charles,

    We are glad to hear you were able to find a workaround for the observed behavior. We agree that this behavior is strange and may likely impact other customers. Thank you for bringing this to our attention. We are communicating with R&D in order to find out the root cause of this and rectify it.

    I will mark this thread as close for the moment. If you have any additional questions or concerns, then feel free to reply to this thread and your reply will re-open the thread.

    Best Regards,

    Jan