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.

CC2640: ADC Hangs in CC2640

Part Number: CC2640

I am ussing cc2640 MCU along with SDK 3_40_00_10. My firmware is based on the simple_peripheral example, with some changes listed below:

- 6 Characteristics with read ans notify permissions.
- 2 Characteristics with write permission.
- 1 Charcteristic that sends the battery level that has read permissions.

I am trying to monitor the battery voltage of my system. However, when I read the value od the analog input using the adc Driver, the code eventually hangs caaling a default HAL_ASSERT and stucks in the HAL_ASSERT_SPINLOCK fuction that is included in the main.c file.

I need to monitor the battery voltage of the system reading the value of the battery from the adc each certain amount of time. Event handlers related to BLE should keep working as well.

This the code I use to read the battery voltage from the ADC:

        ADC_Handle adc;
    ADC_Params adcParams;

    uint16_t adcRawValue;
        uint32_t adcValueMicroVolts;

        ADC_init();
        ADC_Params_init(&adcParams);

    adc = ADC_open(Board_ADC0, &adcParams);
    

        ADC_convert(adc , &adcRawValue);
       adcValueMicroVolts = ADC_convertRawToMicroVolts(adc, adcRawValue );
    ADC_close(adc);


And here is where it gets stuck:

  default:
#if !defined(Display_DISABLE_ALL)
      Display_print0(dispHandle, 0, 0, "***ERROR***");
      Display_print0(dispHandle, 2, 0, ">> DEFAULT SPINLOCK!");
#endif // ! Display_DISABLE_ALL
      HAL_ASSERT_SPINLOCK;

It happens to me either using LAUNCHXL - CC2640, and using analog input DIO23, or using the MCU of my system that includes the 4x4 CC2640 so the analog input used is DIO14.

  • Hi Javier,

    Based on the details you have provided, it looks like you are using CC2640R2F or CC2640R2L. Could you please confirm?

    As you are reaching the AssertHandler() function, we should be able to understand the cause of your issue. It would be nice if you could disable the code optimizer and see if the assert cause can be identified (it is usually not possible with the code optimizer enabled). If the code optimizer cannot be disabled, within the AssertHandler() function, try to set two volatile variables with the value of assertCause and assertSubcause.

    Best regards,

  • Hi Clément,

    Thank you for your response. We are using CC2640R2F, please find attached the images with the experiment you suggested.

    If you can help me identifying what is happening, I will be very thankful.

    Best regards

  • Hi,

    The error handler seems to be caused by HAL_ASSERT_CAUSE_HARDWARE_ERROR.

    Based on this, I think the following code is causing this:

              case HCI_BLE_HARDWARE_ERROR_EVENT_CODE:
                AssertHandler(HAL_ASSERT_CAUSE_HARDWARE_ERROR,0);
                break;

    Could you set a breakpoint in this specific piece of code and see if you could get further insights?

    By the way, I only used the first image you have attached. I am not sure what you wanted to show with the two others. Don't hesitate to point me to something I haven't seen.

    Best regards,

  • Yes. I can confirm you that this is calling the Assert function-

    Do you know why when I get the battery voltage with the ADC, in the same way that in the driver example, this error is fired?

    Best regards

  • Hi,

    Actually, I can say for sure for the moment.

    This event is forwarded to the BLE host layer from the lower layers of the stack (HCI, Controller).

    The cause of this error can be accessed in firmware via the hardwareCode field of the hciEvt_HardwareError_t struct that is sent alongside the event.

    I would recommend parsing the hardwareCode in SimpleBLECentral_processStackMsg(...) under the HCI_BLE_HARDWARE_ERROR_EVENT_CODE.

    Cast the  pMsg to (hciEvt_HardwareError_t *) and read out the hardwareCode.

    The associated error codes are defined in the following files: ll_common.h and hci.h.

    Best regards,

  • Hi Javier,

    Have you managed to solve the issue? Do you need additional help?

    I am going to close this thread for inactivity, if needed, please feel free to open a new thread.

    Best regards,

  • Hi Clément,

    No, unfortunately, it is not fixed. We are still wondering why we get this error using the ADC code provided by Texas Instruments.

    Best regards

  • Hi Javier,

    Have you manage to get the error codes I mentioned in a previous message?

    I understand the issue is only related to the ADC. Have you successfully implemented the ADC in a non-BLE example? Do you want to share a cde snippet showing how you use the ADC? Do you think the ADC could cause some timing issues? Do you have the ADC read in a dedicated task? Have consiered using the sensor controller for the ADC read?

    Best regards,

  • Hi Clément,

    Sorry for the late response, yes, I've finally got the error code. Error code is 0x81, so I assume that it is HW_FAIL_OUT_OF_MEMORY, as shown in common.h

    Is it possible that we have not enough memory for this characteristic? If that is the case, what should we do for allocating some bytes of memory for a new BLE characteristic?

    Regarding the questions related to ADC:

    Yes, I have implemented it successfully in a non-BLE firmware. I do not have a dedicated task for the ADC reading. Would that be recommended?

    What I do so far is reading the ADC inside the BLE task loop whenever I need to. Would that result in timing issues?

    Thank you for your time.

    Best regards

  • Hi Javier,

    Javier Longares said:
    Is it possible that we have not enough memory for this characteristic? If that is the case, what should we do for allocating some bytes of memory for a new BLE characteristic?


    Well, I trust the error code here, so I guess you are out of memory :)
    You may want to follow review the user's guide to find ways to save RAM. You may also want to use the Cache as RAM or the AUX RAM as RAM to increase the total RAM available.

    Javier Longares said:
    What I do so far is reading the ADC inside the BLE task loop whenever I need to. Would that result in timing issues?


    The timing issue does not seem to be the issue here (the memory does). So I will suggest to not use a different task for the ADC.

    Best regards,

  • Hi Clément,

    So, since we are using the same code than the provided from TI for ADC, do you think that the problem is that we don't have enough memory for this characteristic?

    We'll try to add a bit of memory, with the links you have provided.

    Thank you.

  • Hi,

    Javier Longares said:
    do you think that the problem is that we don't have enough memory for this characteristic?

    At least you have an error code showing a memory issue. I cannot say for sure you have no other error.
    My suggestion is to first solve the error we see, then we can see where it leads :)

    Kind regards,