• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 53 subscribers
  • Views 1282 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Can I store manufacturing information in CCA sector of the 2640?

KK
Intellectual 820 points
Other Parts Discussed in Thread: CC2640, BLE-STACK

Hi,

Currently I store manufacturing information in the SNV sector of the CC2640.  While we use 2 sectors (primary and secondary) for SNV, this implies that the manufacturing information, which in theory should read-only, gets copied over to the backup SNV sector every time the primary SNV sector gets above a threshold. 

I find that the CCA sector of the CC2640 is a better location since I do lock sector 31 during the manufacturing process.

Some background here may help. We have multiple products that share a code-base and we use the manufacturing information to determine the product type.  In addition, this area also contains information like datecodes, hardware version numbers, etc. all of which are generated during the manufacturing process.  This information is currently stored in a well-defined inventory structure in SNV.  When a new firmware image is created we ship this off to the manufacturers who then generate the inventory, place it in the appropriate area in memory, i.e., SNV, program the image and inventory into the device, lock the sectors 0 and 31, before running some basic tests on it.  I would like to move this inventory structure to CCA.  BTW, this model uses off-chip OAD.

Some questions for the TI experts:

  1. Do you think it is advisable to move the inventory structure to CCA?
  2. Any problems with writing out this inventory structure, with the Programmer, to CCA, while programming the firmware image?
  3. Can I allocate space in CCA for this inventory structure (about 20 bytes), generate it during the manufacture of the device and store it in the CCA area? 
  4. We do lock Sectiors 0 and 31 (the CCA sector).  Do you foresee any issues in reading this sector from the application during boot-up?
  5. Are there specific routines to access data in CCA?

I appreciate your response.

Regards,
KK

  • 0
    TI__Mastermind 33460 points
    Hi KK,

    1. Assuming that there is space, yes this seems like a good idea based on your system.
    2. You would need to be careful to retain the CCFG which resides at the end of the last flash page. The CCFG's location cannot be changed and is essential for device functionality.
    3. Yes, so long as you have space and are careful to preserve the CCFG
    4. No, the app will be able to read from this space, unused space is left to the app
    5. The regular routines for reading flash can be used, but care must be taken to make these symbols available to the app
  • 0 in reply to Sean2
    Intellectual 820 points

    Hi Sean,

    Thanks for your quick response.  This answers my questions.

    To implement this we need your help in carving out a space for this inventory structure that we referred to earlier.  This gets into the esoteric part of the IAR linker and placement of this structure at the appropriate location and I'm hoping that I can get your help for this.

    We use the IAR IDE environment with BLE Stack 2.1.1 for developing our code for the CC2640.  As mentioned earlier, we use OAD with external flash.

    Here is what I've understood so far about this.

    1. In examining the hex file generated by BIM, I see that the BIM code ends at 0x1F96C in flash, while the CCFG structure starts at 0x1FFA8 and goes all the way to the end of flash for a total of 88 bytes.
    2. In the .icf  file for BIM with external flash, I see a line that says

      place at end of FLASH { readonly section .ccfg };

      I am assuming that this places the 88-byte structure at the end of flash as evidenced by the examination of the hex file generated for BIM.
    3. I see a similar line in the application's .icf file as shown below:

      // CCA
      if ( isdefinedsymbol(RTOS_ROM) )
      {
          place at end of FLASH_LAST_PAGE { readonly section .ccfg };
          keep { section .ccfg};
      }

     

    It seems to me that there is approximately 1590 bytes between the end of BIM and the start of the CCFG structure.  Based on this some questions:

    a) Is it possible that a future release of the BLE Stack will increase the size of the CCFG structure from 88 bytes to a larger number?

    b) If it is a possibility, what is a conservative number to accommodate for this increase?

    c) How do I carve out an area above the CCFG structure in the linker file to a fixed location in Flash? In other words, what are the statements that I need to add to the linker file for this purpose.  The current size of this structure is 20 bytes.  I plan on allocating 64 bytes to be on the safe side.

    I do appreciate your response.

    Regards,
    KK

  • 0 in reply to KK
    TI__Guru** 105180 points

    Hi KK,


    Yes, it is certainly possible that the size of the CCFG structure may grow in future TI-RTOS/BLE-Stack releases - note that it has grown by 4 bytes since initial BLE-Stack v2.0 release. Of course, you can also adjust the location of your structure as a SW upgrade would be required. I would say reserving 128 bytes for the CCFG is prudent.

    One way to specify an absolute location is with the location pragma, see the IAR help menu:

    You can see an example usage of this pragma in the osal_snv.c file. Then you would not need to modify your linker file.


    See the "Controlling data and function placement in memory" section in the IAR help for additional examples as well.

    Best wishes

  • 0 in reply to JXS
    Intellectual 820 points
    Thanks JXS for your response. I will try this out but it does answer my questions.

    Regards,
    KK
  • 0 in reply to JXS
    Intellectual 820 points

    Hi JXS,

    As you mentioned the CCFG structure size increased from 84 bytes to 88 bytes from BLE Stack 2.0.0 to BLE Stack 2.1.1.  

    For  example, let's say I have a device running an image created with BLE Stack 2.0.0 (with the 84-byte CCFG structure) using external flash OAD.  I then move my development environment to say BLE Stack 2.1.1, which uses an 88-byte CCFG structure.  I generate an OAD image (Stack+Application) with BLE Stack 2.1.1 and upgrade this device that was previously using an OAD image based on BLE Stack 2.0.0.  Keeping in mind that the OAD upgrade does not touch Sectors 0 and 31 (or so I am given to understand), here are some questions.

    1. Does TI provide backward compatibility so that the OAD upgrade image generated with BLE Stack 2.1.1 understands that the CCFG structure is 84 bytes because it was created with BLE Stack 2.0.0?
    2. Is there any attempt by BLE Stack 2.1.1 to upgrade the BLE Stack 2.0.0 CCFG structure to bring it in conformance with BLE Stack 2.1.1?  This implies, of course, that it will have to write to Sector 31. Is this true?

    I do appreciate your response.

    Regards,
    KK

  • 0 in reply to KK
    TI__Guru** 105180 points
    Hello KK,

    Regarding different CCFG settings across different TI-RTOS/CC26XXWARE driverlib releases, every attempt is made to maintain backwards compatibility with the previous CCFG structure, however future compatibility cannot always be assured. In the case of BLE 2.0 to 2.1.x the added CCFG word only applies to a feature in the newer driverlib, so the older driverlib from BLE 2.0 will not be affected. Of course, changing the CCFG structure would require writing to page 31 which is not advisable for field-deployed units. In most cases, the CCFG will be configured based on your HW layout, so these changes would not be modified in the field.

    Do you have a specific concern regarding your product already in the field running BLE 2.0? What is your OAD path for these device(s)?

    Best wishes
  • 0 in reply to JXS
    Intellectual 820 points

    Hi JXS,

    Thanks for the explanation on backward compatibility.

    While all our devices in the field are running 2.1.1, I just want to make sure I understand the handling of these scenarios.  I will use 2.a and 2.d as example where 2.d is a later release than 2.a.  We also decide to ignore intermediate releases 2.b and 2.c.

    In our CC2640 device, we use OAD with external flash, where the OAD always upgrades both the Application and Stack simultaneously.  We also lock section 0 and 31, the first and last sectors of our CC2640 device, so there is no question of us ever attempting to rewrite Sector 31, intentionally or unintentionally.

    1. Let's say we run an Application+Stack based on 2.x on our CC2640 devices. Hence the CCFG area is based on 2.a
    2. TI gives us a new release, 2.d, which fixes issues of interest to us.  We decide to take this new release, 2.d, into our development environment.  In turn we decide that we upgrade Application+Stack on devices running 2.a to 2.d.  

    In this situation, will release 2.d handle devices running 2.d Application+Stack but 2.a CCFG?  

    Sorry for being repetitive but if the answer is yes and TI always tests for this scenario, prior to a new release, I will be a happy camper.  Please confirm.

    Regards,
    KK

  • 0 in reply to KK
    TI__Guru** 105180 points
    Hello KK,

    As mentioned, we can't always guarantee future compatibility for software releases that don't exist yet. In most cases, it should be possible to upgrade without need to change the CCFG as it has been in the past. If there is a forward compatibility limitation, then we will disclose accordingly in the release notes and/or porting guide. We do design our updates to be as compatible as permissible, so that should help with future software upgrades. The design goal is to maintain backwards compatibility to the extent permissible.

    Best wishes