CC2640: Porting from BLE stack 2.2.0 to 2.2.1

Hi,

Are you actually using AES encryption, or did you just include that file to get rid of the errors? Also, if you removed common_rom_init.c, how are you getting errors in that file?

-Nathan

Thank you for your reply. I am currently not using it (although I will later on), it just popped up when I ported the project. With regard to r1/common_rom_init.c, its reappearance has to do with rom_jt.c:

#ifdef R2
#include "r2/rom_init.c"
#include "r2/common_rom_init.c"
#else // Default to R1
#include "r1/rom_init.c"
#include "r1/common_rom_init.c"
#endif

Pibe

Hi,

Could you please list the errors that you are getting that need the inclusion of aes.h?

Also, did you make the rom file changes in the stack project or the app project? They need to be made only in the stack project.

-Nathan

So far I was working only in one of the apps, not the stacks. After making the rom-related mods I was getting the error:

#1965 cannot open source file "aes.h" (happening in: ...src/rom/r1/common_rom_init.c)

To address that I looked into the new tree and added an include to the path were I found aes.h:

"${SRC_BLE_CORE}/components/services/src/aes/cc26xx"

That takes care of the error but adds all the others I mentioned in my first post.

With regard to the changes been applicable only to the stack it does not look like that in the wiki. Items 4, 5, and 6 start stating the scope (either application or stack). Item 7 does not specify it and so it would seem like applicable to both. I will try to remove the change from step 7 tomorrow anyway.  Hopefully it is just that. Thanks.

PS: I've just remembered that common_rom_init.c is going to be included one way or the other.  What rom_jt.c does is simply pulling the right file based on the chip release (r1/r2) version. So I do not see how that can affect the outcome.

Pibe

Today I was looking into the TRNG error and found it is originated in TRNGCC26XX.c referencing an external object that does not seem to be defined anywhere:

extern const TRNGCC26XX_Config TRNGCC26XX_config[];

The struct can be found in TRNGCC26XX.h:

/*! @brief TRNGCC26XX Global Configuration */
typedef struct TRNGCC26XX_Config {
    /*! Pointer to a driver specific data object */
    void                   *object;

    /*! Pointer to a driver specific hardware attributes structure */
    void          const    *hwAttrs;
} TRNGCC26XX_Config;

Unfortunately I could not find any indication on how to use this in the documentation available (including the "Technical Reference" which explains the details of the module but not the way this configuration object should be used), and frankly I do not want to guess. Can TI provide support on this? Thanks.

Pibe

Hi,

The code you show shows that it is defined. The error does not look like it has to do with the TRNG files. All of your errors look like they are stemming from including the rom file in the app project and the subsequent steps that you took to fix those errors, which resulted in additional issues.

-Nathan

The linker disagrees, as it complains that TRNGCC26XX_config is not defined.
Also, removing the rom file does not resolve the problem.

Pibe

It's been three days from when I started updating my application from using v2.2.0 to work with v2.2.1. According to common versioning practices, this version number increase should have contained only minor corrections. Instead, the whole tree has been modified and my application does not compile anymore. I have followed the indications to perform the migration as indicated in processors.wiki.ti.com/.../CC2640_Porting_Projects to no avail.

I would appreciate somebody looking into this issue and providing support. Thank you.

Pibe

Hi,

There are only minor changes in this release. The steps in the wiki have been tested on all of the sample applications. Have you tried starting with a 2.2.1 project, copying your project and source files over (as specified in the wiki), and then following only the steps in the wiki (making sure to only add the rom file mentioned in step 7 to the stack project)?

-Nathan

"There are only minor changes in this release."

If it were so I should be able to compile the existent code without problem. Reading the documentation it seems the changes were not minor.

"The steps in the wiki have been tested on all of the sample applications."

That does not mean that it will work on a customer existent project. Not to mention that is not uncommon to find errors in your wikis.

Have you tried starting with a 2.2.1 project, copying your project and source files over (as specified in the wiki), and then following only the steps in the wiki (making sure to only add the rom file mentioned in step 7 to the stack project)?

Why should I? I went through all the documentation already when I picked the part originally.  The project was set up accordingly and you cannot ask your customers to redo everything with every "minor" release.

Pibe

Hi,

I am sorry that you have had issues getting your applications ported. The BLE-stack 2.2.0 can still be used with the CC2650. If you would like to migrate your projects to the 2.2.1 SDK, then you will have to make changes to make the applications work with the changes that were made to the stack in this release. Though minor, these changes still require steps to be taken in the porting process, and the porting guide wiki has the steps that need to be followed.

-Nathan

I resent your "I am sorry" response. Your customers should be more important than your convenience.

The point here is that you made a 2.2.1 release with several fixes needed by those that had already migrated to 2.2.0. Instead of keeping compatibility, you added support for new devices and addressed architectural issues that triggered changes that should have been addressed with another release, like 3.0.0 or so.

I have four controlled projects that now will need to be ported again because of your careless approach.

Pibe