CC2642R: Compilation errors when migrating from MCU CC2640 to MCU CC2642R1 using 26x2 SDK and DeviceFamily_CC26X2

Hi Ryan, Thanks a lot, we are working to resolve the issues, will keep you posted.

Hi Ryan, We followed latest advice to use latest SIMPLELINK-CC13XX-CC26XX-SDK (currently v6.10), we made progress, then we found that file: hiddev.h was missing in this SDK : error: cannot open hiddev.h

We took the hiddev.c and hiddev.h files (and additionally scanparamservice.c and scanparamservice.h since they were required in hiddev) fromgithub.com/.../HOGP-BLE-HID-EXAMPLE, but that led to more errors (see below, including ones related to GAPROLE, we are still yet to update to BLE5 stack). Is this a correct example project to get hiddev.h? 

According to the example you referenced, advParams* are defined in SysConfig and BATT_LEVEL_NOTI_* are defined in the battservice.h file.  If you are attempting to copy over this project's functionality then it may be useful to also import it into your workspace so that you can further compare the project structure and search for files containing text more easily.

Regards,
Ryan

Ok, thanks, acknowledged, we found a lot of changes to be made to our code for CC2640, to make it compile for CC2642R.

One question: We found out that for the WUC ("Wake up Controller"): the drivers for it aren't included anymore in the latest new SDK: SIMPLELINK-CC13XX-CC26XX-SDK (currently v6.10). Is it correct that we do not have WUC anymore and we should be doing operations related to it in a different way now when using the new MCU CC2642R ? 

The CC2652R TRM does not have AON_WUC registers, this is further shown in the CC13X2 and CC26X2 CPU domain registers (compare against the CC26X0R2 CPU domain registers).  It can also be seen when reviewing <sdk_directory>/source\ti\devices\cc13x2_cc26x2 resources.  Thus you will need to accomplish your functionality in another manner.

Regards,
Ryan

Hi Ryan, Is this valid  for CC2642 as well? I mean the absence of AON_WUC registers? You said "accomplish this in another manner". Can you give an example of a solution ?

All CC26X2 devices share the same CPU domain registers.  What were you previously accomplishing through accessing the AON_WUC registers on the CC2640?  You will find that the CC2642 has a more advanced wake-up control and thus should be able to accomplish the application's needs without further user action.

Regards,
Ryan

Hi Ryan, on your question: "What were you previously accomplishing through accessing the AON_WUC registers on the CC2640?"
My reply: We only use constants based on AON_WUC, to:
- check SC active or not;
- start and stop sensor controller.
How should we do this now? Any advice will be very useful. I could not find start/stop commands in the available links and docs.

Our main code in sc_framework.c:
#include <inc/hw_aon_wuc.h>
// Perform sanity checks: The Sensor Controller cannot already be active
if (HWREG(AON_WUC_BASE + AON_WUC_O_AUXCTL) & AON_WUC_AUXCTL_SCE_RUN_EN_M) {

// Start the Sensor Controller, but first read a random register from the AUX domain to ensure
// that the last write accesses have been completed
HWREG(AUX_WUC_BASE + AUX_WUC_O_MCUBUSCTL);
key = scifOsalEnterCriticalSection();
HWREG(AON_WUC_BASE + AON_WUC_O_AUXCTL) |= AON_WUC_AUXCTL_SCE_RUN_EN_M;

// Stop and reset the Sensor Controller Engine
HWREG(AUX_SCE_BASE + AUX_SCE_O_CTL) = AUX_SCE_CTL_RESTART_M;
HWREG(AUX_SCE_BASE + AUX_SCE_O_CTL) = AUX_SCE_CTL_RESTART_M | AUX_SCE_CTL_SUSPEND_M;
HWREG(AUX_SCE_BASE + AUX_SCE_O_CTL);
key = scifOsalEnterCriticalSection();
HWREG(AON_WUC_BASE + AON_WUC_O_AUXCTL) &= ~AON_WUC_AUXCTL_SCE_RUN_EN_M;

One more question: We are getting 4 unresolved symbols in some TI files(see screenshot attached below), these declarations exist in our old board.c code, shall we use them again in our own board.c file replacing the standard, or place them in another file? Any advice will be much appreciated.
In our old project for CC2640 we had these def-s in a private copy of board.c:

/* SPI configuration structure */
const SPI_Config SPI_config[] = {
/* SENSORTAG_CC2650_SPI0 */
{&SPICC26XXDMA_fxnTable, &spiCC26XXDMAObjects[0], &spiCC26XXDMAHWAttrs[0]},
{NULL, NULL, NULL},
};

const I2C_Config I2C_config[] = {
{&I2CCC26XX_fxnTable, &i2cCC26xxObjects[0], &i2cCC26xxHWAttrs[0]},
{NULL, NULL, NULL}
};

I2C_count is also unresolved now, it was defined in the old file I2C.c, which does not exist now.
/* Used to check status and initialization */
static int I2C_count = -1;
If it is obsolete, why does it come as unresolved in the new drivers for M4 processor, our new MCU CC2652 (42): see the screenshot above?

Given the updated Sensor Controller in CC13x2 / CC26x2 devices, these commands should no longer apply.  You can review the CC13x2 CC26x2 Sensor Controller Studio Documentation and SimpleLink Academy Labs for further instructions on interfacing with the Sensor Controller.

Regarding issues with SPI and I2C configurations, these should be added inside SysConfig which will be used in place of a board.c file.

Regards,
Ryan

Hi Ryan, Thanks a lot, we will follow these directions today.