• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 657 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.

CC2640R2F: Debugging BLE stack library project

Chris BD
Prodigy 250 points

Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2640

I'm implementing a split format project to make use of BLE stack placement in ROM on a CC2640R2F, so I have an app project and a linked stack project, and am using CCS as my development tool.

I need to make some changes to the TI library code so that I have more control over flash writes and erasing - I have some fast event processing to perform in the main app.

Can anyone give me pointers on how best (if at all possible) to debug this arrangement as I can only see debugging one side at the moment.

  • 0
    TI__Intellectual 1945 points
    Hi Chris,

    with library code, are you referring to the stack or the app? Because the app you can modify but the stack is closed source.

    Regards,

    Klas
  • 0 in reply to Klas Lofstedt
    Prodigy 250 points
    Hi Klas,

    I'm referring to the "BLE stack" source code that is supplied by TI within the SDK in order to allow for communication with the M0 core of the CC2640 (which I know is closed but is the very lowest layers of the true BLE stack) e.g. ti\simplelink_cc2640r2_sdk_1_35_00_33\source\ti\blestack

    As I understand it this is referred to in all of the examples as "BLE stack" and is usually built as a separate project either as a library for inclusion in the app build or as a separate executable for loading into the extra ROM space of the 2640R2F.

    For example:
    simple_peripheral_cc2640r2_app,
    simple_peripheral_cc2640r2_stack_library and
    simple_peripheral_cc2640r2_stack.

    For the medical device that I'm working on I'll need to make changes to how data is written to flash in order to ensure that it can still react to external interrupts e.g. writing bonding details in 4byte blocks and prevent automated triggering of compaction.

    In order to do this I am creating a project that has all of these BLE stack "library" files included locally, rather than by reference to the TI installation area. This way I can ensure that all files are under our own version control and can be supplied for inspection prior to certification.
  • 0 in reply to Chris BD
    TI__Intellectual 1945 points
    Hi Chris,

    The stack library, even when included locally like you're doing will be closed source and not modifiable. However, what you're trying to do is all possible from just the application code. If the CCS debugging is not enough, i would use a logic analyzer especially for watching interrupts (toggle a pin when you have an interrupt and read it with the logic analyzer).

    Hope this helps.

    Regards,

    Klas
  • 0 in reply to Klas Lofstedt
    Prodigy 250 points
    Ok, just to make sure that we're on the same page here, as I think that we may have a misunderstanding here, as to what is application code and what is BLE stack code.

    Are you saying that any changes that I make to gapbondmgr.c, for example, as found in simplelink_cc2640r2_sdk_1_35_00_33\source\ti\blestack\profiles\roles, will not effect device behaviour?

    So I can't change the maximum number of bonds from 10, prevent possible compaction of flash whenever data is erased or split the saving of bond data to flash into 4 byte blocks rather than all 110 bytes in one go?