Tool/software:
I am in the process of porting an application that works on a CC2652R1 (CC26x2R1 launchpad) and now I am trying to port it to a CC2652R7 but having trouble to get the sensor controller to work. I needed to update simplelink CC13xx CC26xx sdk 7.10 to 7.41 (and also tried 8.30) because otherwise there was some checks for the chip revision that halted the processor. I have updated the linker script and sysconfig to reflect the memory size and device change and my app is now working except for the background operation in sensor controller that scans ADC channels. The app uses radio and and the rf core functionality does work as expected.
I have re-generated the sensor controller code for the R7 with Sensor Controller Studio 2.9.0.208 (patches 1, 2, 3 and 4).
Is there anything else I need to change?
Is the sensor controller in cc2652r1 identical to the sensor controller in cc2652r7?
I am using TI Clang v3.2.0.LTS compiler and CCS v20.1.0.6
Best regards /Ruben
Hi Ruben,
Does your CC2652R1 SCS ADC code work with F2 SDK v7.41 or v8.30? The Sensor Controller is identical between the CC2652R1 and CC2652R7 but SCS v2.9 and patches 1/2/3/4 only support up to F2 SDK v7.10 as far as I'm aware.
I'm not aware of any chip revisions which should halt the processor when used in F2 SDK v7.10, would you be able to expand on this?
Regards,
Ryan
Hi Ryan and thanks for your quick response, appreciate it.
We have until now been developing the firmware on a LAUNCHXL-CC26X2R1 which has a CC2652R1F chip. The real board is now being developed and for that it was decided to use a CC2652R7 chip (exact PN# CC2652R74T0RGZR). Because of this we bought a bunch of LP2652R7 launchpads which has a CC2652R74 chip mounted on them. The final device uses 3 boards per set and we need to run a couple of sets here simultaneously when we develop the firmware.
My task now is to prepare for developing with the new CC2652R7 launchpad. The final device will also have a BLE OAD firmware downloader which is also working with the old CC26X2R1 launchpad.
The firmware has up until now been developed using the simplelink SDK v7.10 and here the sensor controller software works as intended together with the rest of the app on the CC26XR1 launchpad. .
After updating the linkerscript for the CC2652R74 (to reflect the larger flash and ram memory, mainly for the OAD part), changing the device in the sysconfig tool and added the DeviceFamily_CC26X2X7 symbol to the compiler and linker the code builds (still using the SDK v7.10). However when I run the code on the CC2652R7 launchpad it doesn't get past the Boot_trimDevice() function but stops in NOROM_ThisLibraryIsFor_CC13x2_CC26x2_HwRev20AndLater_HaltIfViolated(). So I figured I will try to update to a later SDK and downloaded Simplelink SDK v7.41 (Simplelink CC13xx CC26xx SDK) and then the code successfully gets past the Boot_trimDevice() function and runs the rest of the app. Or, so I thought. It turns out that when I start the task in the sensor controller which samples the a/d channels, it never alerts the main firmware that new samples has arrived. This is the only task running in the sensor controller and everything is done in the event handler. We also tried to just set a LED with the sensor controller code at the start of the event but this doesn't seem to work either. At this point the OAD software is not added. There is a lot of radio communication going on and this seems to work as intended.
I have never worked with the Sensor Controller Studio before (someone else has developed that code) but since it also requires me to set the device (chip name) i figured that this code needs to be re generated.
Please advise me how to proceed. Which SDK and Sensor Controller Studio versions (and patches) I need to use to get this to work.
Thanks in advance /Ruben
After some additional debugging I have got it to work. The sensor controller does indeed work but the problem was that code in it seems to just stop and doesn't trigger an alert to the main processor. This in turn seems to be connected to a timer issue. I got it to work as intended by tweaking a timeout value which turned out to be slightly too short on the R7 chip.
Thanks /Ruben