CC2650: Code execution freezes at a low level during I2C communications

Dale,

Can you provide some information about which SDK you are using? Have you tested your code on a LaunchPad to ensure there isn't a hardware issue? Are you using the I2C driver from the SDK? Any modifications? 

It would also be helpful to see what the code around the area where it hangs. Have you tried verifying that your I2C driver/handle are configured and opened properly? Is there a specific drive API where the hang occurs?

Thanks,

Daniel

Hi Daniel,

daniel_o said:

Can you provide some information about which SDK you are using?

I am using the 2.2.1 BLE stack and here is CSS General tab for the main project (I am not sure what else the SDK would refer to):

daniel_o said:

Have you tested your code on a LaunchPad to ensure there isn't a hardware issue?

That is a good idea, I will attempt that at some point.

daniel_o said:

Are you using the I2C driver from the SDK?

I am using this include file to add I2C to the main project:

#include <ti/drivers/I2C.h>

daniel_o said:

It would also be helpful to see what the code around the area where it hangs.

See my comment at the bottom of this code snippet from my modified Project Zero:

static void ProjectZero_taskFxn(UArg a0, UArg a1)
{
  Halo_init(); //dale

  // Initialize application
  ProjectZero_init();

  // Application main loop
  for (;;)
  {
    // Waits for a signal to the semaphore associated with the calling thread.
    // Note that the semaphore associated with a thread is signaled when a
    // message is queued to the message receive queue of the thread or when
    // ICall_signal() function is called onto the semaphore.
    ICall_Errno errno = ICall_wait(ICALL_TIMEOUT_FOREVER);

    if (errno == ICALL_ERRNO_SUCCESS)
    {
      ICall_EntityID dest;
      ICall_ServiceEnum src;
      ICall_HciExtEvt *pMsg = NULL;

      // Check if we got a signal because of a stack message
      if (ICall_fetchServiceMsg(&src, &dest,
                                (void **)&pMsg) == ICALL_ERRNO_SUCCESS)
      {
        uint8 safeToDealloc = TRUE;

        if ((src == ICALL_SERVICE_CLASS_BLE) && (dest == selfEntity))
        {
          ICall_Stack_Event *pEvt = (ICall_Stack_Event *)pMsg;

          // Check for event flags received (event signature 0xffff)
          if (pEvt->signature == 0xffff)
          {
            // Event received when a connection event is completed
            if (pEvt->event_flag & PRZ_CONN_EVT_END_EVT)
            {
              // Try to retransmit pending ATT Response (if any)
              ProjectZero_sendAttRsp();
            }
          }
          else // It's a message from the stack and not an event.
          {
            // Process inter-task message
            safeToDealloc = ProjectZero_processStackMsg((ICall_Hdr *)pMsg);
          }
        }

        if (pMsg && safeToDealloc)
        {
          ICall_freeMsg(pMsg);
        }
      }

      // Process messages sent from another task or another context.
      while (!Queue_empty(hApplicationMsgQ))
      {
        app_msg_t *pMsg = Queue_dequeue(hApplicationMsgQ);

        // Process application-layer message probably sent from ourselves.
        user_processApplicationMessage(pMsg);

        // Free the received message.
        ICall_free(pMsg);
      }
    }
    if (iamawake) { //dale3-28 CC2640 has woken up and is BLE advertising
        if (events & PERIODIC_DALE_CYCLE) { //dalecycle 1/4 second for I2C testing 
            events &= ~PERIODIC_DALE_CYCLE; //dalecycle clear event
            Util_startClock(&periodic_dale_cycleClock);//dalecycle
			
            if (justwokeup) {//2020 added so that plugging in battery finishes initialization
                initI2CdevicesAndGetUID();  // I believe the program execution hangs in this function 
								// but if this function is executed outside this 'Application main loop' 
								// in the Halo_init() function (see above), it completes without hanging
                justwokeup= 0;
            }

daniel_o said:

Have you tried verifying that your I2C driver/handle are configured and opened properly?

Yes I2C works fine as I noted above, the initI2CdevicesAndGetUID() function works when run from inside my Halo_init() function in the above code snippet, but hangs when run in the 'Application main loop'.

daniel_o said:

Is there a specific drive API where the hang occurs?

How can I tell what API it is in?

I really believe that I should not likely be running I2C communications in the 'Application main loop' with I2C in blocking mode.  That long initI2CdevicesAndGetUID() function needs to be run every time the Cc2650 wakes up from sleep and I need to do some short I2C bursts every few seconds while it is awake.  These periodic I2C bursts do not hang the code and BLE communications work fine with these short periodic I2C bursts.

If the proper way to add I2C to a BLE workspace is to use I2C in callback mode I would really like to figure how to do that but I can not find any example code to get me started, if not, then I have to figure out how to avoid this freezing.

Dale

daniel_o said:

Have you tested your code on a LaunchPad to ensure there isn't a hardware issue?

I have just looked into this possibility but since my code needs external hardware to run (I read and write to external flash memory), I do not think it is worth changing my code or adding the external components to the launchpad to get I2C and BLE communications working on the launchpad.  Even if I did, the answer of whether it works on the Launchpad is I think sortof meaningless at that point.  My modified Project Zero has been performing in the field on 1000's of CC2640F128 installations for 3 years without BLE com issues... These BLE com issues are only appearing since I added I2C funtionality.

MORE INFO:

To integrate I2C into my modified Project Zero, I used the "i2ctmp007" example project.

I copied the I2C related code from that example codes' Board.h , CC2650STK.c , CC2650STK.h  and i2ctmp007.c files.  I also made sure that the SCA and SCL pins were directed in code to the output pins that my physical I2C bus was attached to.

All my short I2C communications with three bus devices work fine when inside the 'Application main loop', and the long initI2CdevicesAndGetUID() function works without hanging if it is outside the 'Application main loop'.

In all cases, the problem seems to to be that I2C is interfering with BLE communications, sometimes BLE handshaking works but BLE data transfer and button presses never work with BLE code that has been working for years.

Dale,

Thanks for the additional information and debugging steps. I'm reaching out to a BLE stack expert to comment since it seems to be related to the BLE stack rather than the I2C.

Thanks,

Daniel

Thanks Daniel...

MORE INFO:

I no longer believe that this is a Blocking versus Callback issue for I2C communications.

My reason for thinking that is explained by the results of this code and the comments in this code snippet:

  static void Halo_init(void){ //dale
    openPins(); //Not the I2C pins though
    if (useI2C) { //If useI2C = 0 then there is no I2C initialized, opened or transactions attempted.
                  //If useI2C = 0 then all BLE comms work as expected, as it has for the last 3 years.
        Board_initI2C(); //this is equivalent to I2C_init ();
        I2C_Params_init(&I2Cparams);
        I2Cparams.bitRate = I2C_400kHz;
                  //If useI2C = 1 then all I2C comms work fine but BLE comms get messed up as below
    } else {
        // Setting useI2C = 0 and un-commenting the below Board_initI2C(); line causes:
        // 1. Intermittent BLE handshaking success
        // 2. ON/OFF button events NOT to be sent to iPhone on BLE
        // 3. Sending data on BLE to the iPhone stops working
        //Board_initI2C(); //this is equivalent to I2C_init ();
    }

In my first code snippet (previous post), you can see that Halo_init() is run at the beginning of the ProjectZero_taskFxn() yet still outside of the 'Application main loop'.

Note: I have moved the long initI2CdevicesAndGetUID() function to where it runs whenever the CC2650 wakes up from sleep and before the BLE is told to advertise again after sleeping. This eliminates the low level freezing that was mentioned in my first post of this topic but there are still unworkable BLE com issues remaining.

It really appears to me that my implementation of the TI I2C library in my modified Project Zero is causing the BLE com issues.

Is there another conclusion that could be drawn which I am missing?

Hi Dale,

I do not think that initializing the I2C in this part of task code is correct.

f (justwokeup) {//2020 added so that plugging in battery finishes initialization
initI2CdevicesAndGetUID(); // I believe the program execution hangs in this function
// but if this function is executed outside this 'Application main loop'
// in the Halo_init() function (see above), it completes without hanging
justwokeup= 0;
}

Should be in ProjectZero_init()

Also you initialize the I2C twice, which may be causing your issue.

Another is that I do not recommend you to use the Project Zero as base for your project, it is a demo example program with its own application implementation. The recommended project base is Simple Peripheral.

Also, if you are new to this I suggest you use the Launchpad and try to send temperature data over Bluetooth to get familiar.

-kel

Markel Robregado said:

Should be in ProjectZero_init()

Why? As I have shown, My Halo_init() is run before ProjectZero_init(), what problem could that cause?

Markel Robregado said:

Also you initialize the I2C twice, which may be causing your issue.

I fail to see where I initialize I2C twice... My I2C init code snippet was made so that I can easily debug this issue by switching between good BLE coms and bad BLE coms.  If I want to have good I2C communications and no I2C, I initialize 'useI2C = 0' and if I want to add I2C functionality (which successfully communicates with three I2C bus devices) to my operating BLE code I initialize 'useI2C = 1' which causes BLE com issues.  Then, to see what may cause the BLE com issues I initialize 'useI2C = 0' and add un-comment  the second = I2C init line after the 'else' and only this SINGLE process of initializing I2C causes the BLE com issues.  How much closer than this do I need to get in order to isolate this issue as being the fact that initializing I2C causes my BLE com issues?

Markel Robregado said:

Another is that I do not recommend you to use the Project Zero as base for your project, it is a demo example program with its own application implementation. The recommended project base is Simple Peripheral

The decision to use Project Zero base code was made in 2017 and I spent hundreds of hours back then developing my modified Project Zero, my iPhone app and my CC2640F128 circuit board.  It is highly unlikely that I will start over.  There are 1000's of circuit boards and modified Project Zero's out there that have been working for 3 years WITHOUT BLE issues.  With BLE, I transfer data to and from my iPhone, button state events are sent to my iPhone.  There is also code that I added to my Project Zero which transfers data to and from an external flash chip with the CC2640F128.

Markel Robregado said:

Also, if you are new to this I suggest you use the Launchpad and try to send temperature data over Bluetooth to get familiar.

I am not sure how to reply to this, except with calmness.  I got past being able to send data over Bluetooth a long time ago.

Dale Kramer said:

I fail to see where I initialize I2C twice

Isn't the second I2C initialization here initI2CdevicesAndGetUID();? As you have mentioned you hang at this part, what are the details of this C function that causes this hang?

As you have mentioned the original base code works. So, you have to figure out what have changed from the old implementation to now that is causing this issue.

If you ported this CCS project to use the latest BLE Stack, then maybe there are some changes, improvements, bug fixes.

Dale Kramer said:

The decision to use Project Zero base

A lot use the Project Zero as base as this is a demo and used in SimpleLink Academy lectures. But, then here they would recommend Simple Peripheral due to a lot of good reasons, its a long explain. So, when you you use Project Zero as base for your product development it becomes a pitfall.

Dale Kramer said:

am not sure how to reply to this, except with calmness.  I got past being able to send data over Bluetooth a long time ago.

If you ported old CCS project to use latest BLE Stack, its not a bad idea to evaluate the peripherals that you need to use also Bluetooth communication.

-kel

Markel Robregado said:

Isn't the second I2C initialization here initI2CdevicesAndGetUID();? As you have mentioned you hang at this part, what are the details of this C function that causes this hang?

I think that the name of my function 'initI2CdevicesAndGetUID()' misleads you into thinking that I have an I2C_init in there.  The name is referring to initialization of I2C bus devices that have just had their power pin become active when I energize the I2C bus by enabling a voltage regulator on the I2C power line.   I do open an I2Chandle in the function though. I think I have explained how I got rid of the hanging by moving this function to be the first code that the CC2640 executes after it wakes up from sleeping.  I also close the I2Chandle if it is open just before the CC2640 goes to sleep.  SO THERE IS NO HANGING ISSUE ANYMORE.  BUT BLE COMMS still have issues the second that I initialize I2C.

Markel Robregado said:

If you ported this CCS project to use the latest BLE Stack

I can not imagine how long that would take me to do, although not new to this, I am still a novice..... and what guarantee would I have that this issue would be solved?

Markel Robregado said:

A lot use the Project Zero as base as this is a demo and used in SimpleLink Academy lectures. But, then here they would recommend Simple Peripheral due to a lot of good reasons, its a long explain

In 2017 when the Project Zero decision was made, I had a LOT of forum threads and help to accomplish my goals by a lot of TI employees.  I don't remember nor can I find a recommendation from them to use Simple Peripheral instead :(

Markel Robregado said:

If you ported old CCS project to use latest BLE Stack, its not a bad idea to evaluate the peripherals that you need to use also Bluetooth communication.

You would get tired of all the questions I would need answered to accomplish this, starting with the fact that I do not even fully understand what you are proposing that I do.

EDIT:  I really think that I have isolated this issue well enough for someone who really knows what is happening 'under the hood' here to easily provide the solution, at least I have to hope so since I do not think I can debug this any further on my own...

Hi Dale,

I have tried reviewing all that has been said so far on this thread. Please accept my apologizes if I have missed something. 

First of all, we usually recommend to use simple_peripheral examples but it absolutely does not mean you have to migrate your project to this example. Regarding migration to a newer SDK / BLE stack, it is true we usually recommend this but I would suggest to first solve the issues with the I2C driver. Then you can consider doing the migration based on the new features / bug fixes / optimizations implemented in the newer BLE Stack.
In summary, let's try to solve you issue without changing the example nor the BLE stack version :)

May I ask you if you have verified if the issue is caused by any sort of stack corruption or heap shortage? I mean, by adding the I2C driver I suppose you have also added a few buffers consuming some RAM... It cold be nice if you used the ROV or ROV Classic as described in this document to verify the stack usage. Still using the same document, you will find some ways to debug heap issues, it might worth reviewing it.

Another idea I have is to verify how much time the CPU is blocked by the code related to the I2C initialization [you could do the measurement by toggling a pin right before and right after, CCS debugger may also be ale to masure this timing for you]. BLE operations are really time sensitive and any unwanted delay will lead to something bad. If the amount of available RAM allows it, you may want to move all the I2C operations to a different thread with a lower priority. That way you would eliminate the problem.

Last element, you could import the source code of the I2C driver inside your CCS project. That way you will be able to step in the I2C code. Not 100% sure it will be helpful in this situation but it might be in other cases.

Let us know if this leads to other interesting observations,

Kind regards,

Clément said:

let's try to solve you issue without changing the example nor the BLE stack version :)

Music to my ears :)

Clément said:

May I ask you if you have verified if the issue is caused by any sort of stack corruption or heap shortage?

Please excuse me if I do not understand some of your questions, I am new to this level of debugging.  This question does make sense as a possibility as I know that I did some stack size optimization back in 2017 as my code was rather close to using up code space.

Here is ROV Classic System stack before I2C_init():

Here is ROV Classic System stack after I2C_init():

Here is some more info of my project with regard to memory:

Clément said:

Another idea I have is to verify how much time the CPU is blocked by the code related to the I2C initialization [you could do the measurement by toggling a pin right before and right after, CCS debugger may also be ale to masure this timing for you]. BLE operations are really time sensitive and any unwanted delay will lead to something bad.

I am having difficulty with this concept since currently the location of the I2C_init() is outside of the 'Application main loop' where iCall messages are used.  Why would a CPU usage time length during my I2C_init() matter at this point that I do the I2C_init()?  I can do the pin toggle if you want and measure the time with my scope if you really think this is needed, please confirm that it is or is not... 

Clément said:

If the amount of available RAM allows it, you may want to move all the I2C operations to a different thread with a lower priority. That way you would eliminate the problem.

Yes I would like to try this suggestion but I would need step by step instructions to do it.

Clément said:

Last element, you could import the source code of the I2C driver inside your CCS project. That way you will be able to step in the I2C code. Not 100% sure it will be helpful in this situation but it might be in other cases.

I will try this and report back :)

Thanks for jumping in !

Dale

EDIT: For completeness here is the memory usage of my BLE221 stack:

Dale Kramer said:

Clément

Last element, you could import the source code of the I2C driver inside your CCS project. That way you will be able to step in the I2C code. Not 100% sure it will be helpful in this situation but it might be in other cases.

I will try this and report back :)

It sure would be nice to debug step through the I2C code but I can't seem to find the source code for I2C_init() function in order to test this concept for this specific function which seems to cause these BLE com issues....  Any idea where I can find it?

Hi,

Dale Kramer said:

It sure would be nice to debug step through the I2C code but I can't seem to find the source code for I2C_init() function in order to test this concept for this specific function which seems to cause these BLE com issues....  Any idea where I can find it?

As you may have some function pointers are use in I2C.c. If you want to access the actual code, you have to find the file I2CCC26XX.c. In the case of CC2650, this code should be in tirtos_cc13xx_cc26xx_X_XX_XX_XX\products\tidrivers_cc13xx_cc26xx_2_21_01_01\packages\ti\drivers\i2c. For CC26XX, it is in <SDK>\source\ti\drivers

Best regards,

Hi,

Dale Kramer said:

Please excuse me if I do not understand some of your questions, I am new to this level of debugging

In plain English, I ask if you are running out of RAM ^^

Dale Kramer said:

Here is ROV Classic System stack before I2C_init():

Could you also look at the module "Task"? There you should be able to find the stackPeak.

Best regards,

Clément said:

In plain English, I ask if you are running out of RAM ^^

OK, I do not think so 

Clément said:

Could you also look at the module "Task"? There you should be able to find the stackPeak.

Immediately before I2C_init():

Immediately after I2C_init():

OK I copied the four files (I2C.h/.c and I2CCC26XX.h/.c) into my workspace directory and I was immediately able to debug step through them.

Not much happens on an I2C_init(), basically just this line of any consequence that I can tell 'object->isOpen = false;' shown here:

Hi Dale,

You are now sett-up for debugging :)

There are a few elements that I haven't understood. Could you do the following for me?

• identify if the problem is due to I2C_init(), I2C_open() or rather to the transfers afterwards [to do so, I would recommend to comment out all the I2C functions except I2C_init(). Once you have confirmed I2C_init is not the source of the issue, try to de-comment I2C_open()]
• provide some details on the state of the device after the problem has occurred. If I am correct you are not longer experiencing a hang, correct? So what does the device do? Is it still executing some code? If yes, which function?
  I usually recommend to run the code with the debugger attached until the problem appears. Once the problem is there, pause the execution.
  • Using the ROV verify the state of the different tasks, verify that no exception has occurred (hwi module)
  • Try to identify which piece of code is being executed (use the step by step execution, it should help to see if you are in an infinite loop or something like this)
    

Last but not least, if not already done, I strongly recommend reviewing this document.

Best regards,

Clément said:

identify if the problem is due to I2C_init(), I2C_open() or rather to the transfers afterwards [to do so, I would recommend to comment out all the I2C functions except I2C_init(). Once you have confirmed I2C_init is not the source of the issue, try to de-comment I2C_open()]

I am sorry that I can not confirm that I2C_init() is NOT the source of the issue. My below debugging code snippet (that I have already posted) describes how I had already isolated the I2C_open() and transfers by initializing with 'useI2C = 0'.  Then I2C_init(), I2C_open() and all transfer code does not execute and which give me working BLE comms...  Then, with 'useI2C = 0' I Un-comment the 2nd I2C_init() which then executes ONLY I2C_init and NO other I2C code and my BLE comms are not working as described in that debug code snippet.   SO, I think I already HAVE shown that I2C_init() alone causes the BLE comm issues...

Clément said:

If I am correct you are not longer experiencing a hang, correct?

Correct.

Clément said:

So what does the device do? Is it still executing some code? If yes, which function?

  static void Halo_init(void){ //dale
    openPins();
    if (useI2C) { //If useI2C = 0 then there is no I2C initialized, opened or transactions attempted.
                  //If useI2C = 0 then all BLE comms work as expected, as it has for the last 3 years.
        Board_initI2C(); //this is equivalent to I2C_init ();
        I2C_Params_init(&I2Cparams);
        I2Cparams.bitRate = I2C_400kHz;
                  //If useI2C = 1 then all I2C comms work fine but BLE comms get messed up as below
    } else {
        // Setting useI2C = 0 and un-commenting the below Board_initI2C(); line causes:
        // 1. Intermittent BLE handshaking success
        // 2. ON/OFF button events NOT to be sent to iPhone on BLE
        // 3. Sending data on BLE to the iPhone stops working
        //Board_initI2C(); //this is equivalent to I2C_init ();
    }

With the above debug code 'as is' and useI2C initialized at 1, there is no hanging and the following DOES NOT WORK any more:

1. BLE communications accomplishes intermittent handshaking success
2. BLE transfer of my notices about the occurrence of button events no longer get thru to the iPhone if handshaking does occur.
3. BLE transfer of data packets no longer reach the iPhone if handshaking does occur.

AND following DOES WORK and the code can be stopped with breakpoints and F5... etc debug stepped thru:

1.  I2C successfully communicates with three I2C bus devices (a RC522 based RFID reader, an I2C air pressure sensor and a BME280 temp/humidity sensor.
2. Button events occur.
3. Data is written to my external flash chip for later transfer to iPhone by BLE.
4. Basically everything works and executes as normal for the last 3 years AND with my new I2C communications working EXCEPT that BLE comms have the above noted issues.

Clément said:

I usually recommend to run the code with the debugger attached until the problem appears.

I have been able to debug with the XDS110 on the CC2650 Launchpad for the last 3 years.

I have used ROV before, about 3 years ago.

The only infinite loop has been taken care of as described in the first few posts of this topic.

Clément said:

Last but not least, if not already done, I strongly recommend reviewing this document.

I have used that document MANY times in the last 3 years.

This post should be a very good summary of all the posts of the topic to date.

I would be happy to demonstrate the above to you in a Chrome Remote Desktop support session.

EDIT: The above Halo_init() function is executed in Project Zero directly before ProjectZero_init():

static void ProjectZero_taskFxn(UArg a0, UArg a1)
{
  Halo_init(); //dale
  // Initialize application
  ProjectZero_init();
  // Application main loop
  for (;;)
  {
    // Waits for a signal to the semaphore associated with the calling thread.
    // Note that the semaphore associated with a thread is signaled when a
    // message is queued to the message receive queue of the thread or when
    // ICall_signal() function is called onto the semaphore.

Hi,

Thank you for the details. I was not sure to well understand because it is quite surprising to see issues created by the init function of a driver. Could you verify if the system initialize only one I2C driver (as it should)? (this can be seen by stepping through the I2C_init function and looking at I2C_count).

Best regards,

Clément said:

Could you verify if the system initialize only one I2C driver (as it should)? (this can be seen by stepping through the I2C_init function and looking at I2C_count).

Yes only 1, that was the first thing I confirmed yesterday when I was able to step through the I2C code, sorry I did not report that fact.

Last element that worth to be verified in the I2C_init function is the content of I2C_config. In addition, could you provide an extract of the boardfile showing how you configure the I2C driver?

Regards,

Clément said:

could you provide an extract of the boardfile showing how you configure the I2C driver?

In board.h:

#define     Board_I2C0              Board_I2C  //daleI2C
#define     Board_I2C_TMP           Board_I2C0 //daleI2C
#define     Board_initI2C()         I2C_init() //daleI2C

In my HaloLoggerV1a.h"

In my HaloLoggerV1a.c:

 *  ============================= I2C Begin=====================================
*/
/* Place into subsections to allow the TI linker to remove items properly */
#if defined(__TI_COMPILER_VERSION__)
#pragma DATA_SECTION(I2C_config, ".const:I2C_config")
#pragma DATA_SECTION(i2cCC26xxHWAttrs, ".const:i2cCC26xxHWAttrs")
#endif

/* Include drivers */
#include <ti/drivers/i2c/I2CCC26XX.h>

/* I2C objects */
I2CCC26XX_Object i2cCC26xxObjects[CC2650_LAUNCHXL_I2CCOUNT];

/* I2C configuration structure, describing which pins are to be used */
const I2CCC26XX_HWAttrsV1 i2cCC26xxHWAttrs[CC2650_LAUNCHXL_I2CCOUNT] = {
    {
        .baseAddr = I2C0_BASE,
        .powerMngrId = PowerCC26XX_PERIPH_I2C0,
        .intNum = INT_I2C_IRQ,
        .intPriority = ~0,
        .swiPriority = 0,
        .sdaPin = Board_I2C0_SDA0,
        .sclPin = Board_I2C0_SCL0,
    }
};

/* I2C configuration structure */
const I2C_Config I2C_config[] = {
    {
        .fxnTablePtr = &I2CCC26XX_fxnTable,
        .object = &i2cCC26xxObjects[0],
        .hwAttrs = &i2cCC26xxHWAttrs[0]
    },
    {NULL, NULL, NULL}
};
/*
 *  ========================== I2C end =========================================
 */

Clément said:

Last element that worth to be verified in the I2C_init function is the content of I2C_config

Sorry, I can not find "I2C_config" text in any of my workspace files nor any file with that in its name on my computer.  Where do I find this?

Hi,

Dale Kramer said:

Sorry, I can not find "I2C_config" text in any of my workspace files nor any file with that in its name on my computer.  Where do I find this?

Actually you do have provided the code defining I2C_config :)

I cannot find any issue there.
The diagnostic you have suggested (i.e. a problem due to I2C_init) makes less and less sense to me. I mean, this function writes a few variables and does not rise any error. Once again, the I2C_init function has no real effect on the I2C module hence my doubts. The function I2C_init may be highlighting an issue due to a heap corruption or slightly modifying the timing. 

Could you please try to get the heap / stack details I asked in one of my previous messages? This is the only element I see to progress in this debugging effort.

Best regards,

Clément said:

Actually you do have provided the code defining I2C_config :)

Ooops, sorry I must have had faulty search parameters for that when I did my workspace search, or maybe I did a dyslexic search :) 

Clément said:

Could you please try to get the heap / stack details I asked in one of my previous messages?

I thought I provided that with my ROV Hwi and Task screen shots.  Sorry to be so lame here but how do I find these  heap / stack details you are requesting?

Hi,

Actually the screenshots you provided in one of your previous message were fine, but it would be nice if we could look at the same ones after 5 minutes of execution. To do so, let the device running freely (try to establish a connection with the phone) then after 5 minutes, connect the debugger, pause the execution and verify the results provided by the ROV.

Regards,

That is a nifty trick to debug a running CC2640 :)

But after 15 minutes of running with BLE handshaking not happening in iPhone, I put in a break after I triggered an RFID tag read using the working I2C code.

Here are the ROV Hwi and Task status at the break:

Hi,

Could you do the same test with the I2C transfers commented out? (i.e. only keep I2C_init)

Regards,

I would if I could.

So that I could debug with a reset, build etc as before, put back the 4 Gel reset lines into code, I changed the 2 checkboxes back on my Debug configuration 'Program' and 'Target' tabs...  Then I tried to start a debug session but the code freezes again but this time in the BIOS_start() function :(

I have tried all manner of resets, power cycles, CCS close/opens etc but this is consistent hang again.

I put a breakpoint on BIOS_start() and then press F5 and then it hangs, here is the assembly after I break in the hang:

I tried Ctrl+Shift F5 presses from the BIOS_start() breakpoint but I it was taking too long to get to the hang code so I gave up.... :(

EDIT: I also created a new workspace and imported a archived backup (working code) of my workspace that was archived on Jan 13...... Same BIOS_start() FREEZE :(

EDIT2: I can use Flash Programmer 2 to load the hex file we have been using for 3 years onto the cc2640 and the code runs perfectly and does all BLE comms the iPhone app without failure or delay...

Hi,

Ok, does the same happen if you run the code in debug mode from the beggining?

Could you try to flash the device using an external tool such as Flash Programmer or Uniflash? (I wonder if at one point the modification you made earlier to be able to connect the running target may be the reason of your difficulties)

Regards,

Clément said:

Could you try to flash the device using an external tool such as Flash Programmer or Uniflash?

Yes, I did my EDIT2 to previous post at same time as you asked this question....

Clément said:

Ok, does the same happen if you run the code in debug mode from the beggining?

Unsure of this question???? I was running in debug mode to even get to the breakpoint on BIOS_start() line so I do not understand? Is debug mode something other than being able to step through my code?

Also loading the current hex files from the debug directories of the latest build with Flash Programmer 2 works and the code runs without hanging (my LED is flashing, my proof of life led on my pcb ;) )...

And now, without doing a thing, other than starting a new debug session in CCS after I just loaded the current Hex files with FP2, there is NO LONGER A HANG IN BIOS_Start()..........

I HATE INTERMITTENTS .......... what a waste of time at 5am here....

OK, with ONLY I2c_init() added to my working BLE comms code like this:

  static void Halo_init(void){ //dale
    openPins();
    useI2C = 0;  //set here instead of initializing it on program reset
    if (useI2C) { //If useI2C = 0 then there is no I2C initialized, opened or transactions attempted.
                  //If useI2C = 0 then all BLE comms work as expected, as it has for the last 3 years.
        Board_initI2C(); //this is equivalent to I2C_init ();
        I2C_Params_init(&I2Cparams);
        I2Cparams.bitRate = I2C_400kHz;
                  //If useI2C = 1 then all I2C comms work fine but BLE comms get messed up as below
    } else {
        // Setting useI2C = 0 and un-commenting the below Board_initI2C(); line causes:
        // 1. Intermittent BLE handshaking success
        // 2. ON/OFF button events NOT to be sent to iPhone on BLE
        // 3. Sending data on BLE to the iPhone stops working
        Board_initI2C(); //this is equivalent to I2C_init ();
    }

Here are your ROV stats at a break after 10 minutes of running with no BLE handshaking accomplished (I just set a breakpoint in a periodic event where I flash my 'sign of life' led in the ICALL loop):

Hi Dale,

Thank you for this. 
The problem is that nothing is indicating where we should look.

Could you do the same test without any I2C function (not even the I2C_init)?

Regards,

Hi Dale,

It is good to know that you have found a solution to your problem and able to move forward. The ideal way is to port your code to an example program of latest BLE Stack. During, the porting verify every functionality of the program. This is more like start everything from scratch. It's a lot of work but doable. 

If this forum is not enough to help with your issues. There, are alternatives such your company hiring a technical consultant to get over this obstacle, so you will have a working program running at your hardware.

-kel

Hi Markel,

What would challenge my brain if I hired experts to do all the fun work?  I think life is about learning until you die.  I am thankful for all the help here and hope others will find my struggle helpful in this most extremely complex product space.  I know I complain a lot but please take it with a grain of salt, I mean no harm.  I doubt that I will port this project to the latest and greatest BLE stack (if I could do it in a day, perhaps, but I do not think so).   For the foreseeable future I have too many other things to conquer.  Google me and you may further understand my position on this.

Now on to the next fire in this project...

Dale

Hey Dale,

Well done in figuring that out!

I'll be happy to help you for the "next fire" :)

Best,

Clément said:

I'll be happy to help you for the "next fire" :)

Thanks, but you may be sorry you said that ;)