This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52832-CIAA BLE NOT WORKING

Hi All,

can any one tested BLE on nRF52832-CIAA?

Actually we have a nRF52-DK and also our application board.

in both the boards we loaded DFU project to check BLE connectivity. in nRF52-DK, BLE function works great. but in our application board (nRF52832-CIAA) we cannot see the BLE advertising (32MHZ crystal is also not resonating)

please let us know what is the issue?? early response will be appriciated..

below attached the schematics.

image description

Parents Reply Children
  • FormerMember
    0 FormerMember in reply to Gopal

    I have updated my answer, see both "updates".

  • Hello Kristin,

    can you give your official mail ID. i will try to send you one of our board for testing.

  • FormerMember
    0 FormerMember in reply to Gopal

    Could you check if it works to run the chip in debug mode?

    What happens if you try to start the HFCLK manually?

    Could you also check that the 32 MHz crystal has been correctly mounted, i.e. not shifted by 90 degrees for instance?

  • Checking with Debug Mode -

    Below code (softdevice_handler_init) is from softdevice_handler.c, we are always able to hit the break point at line 273, first line of the function. After that the code does not return to the next line or a break point placed on the next executable source line. for eg: 293. (This is generally the case). When we stop the debugger, we find ourselves looping at this code.

    0x000090F2 BF20      WFE           
    0x000090F4 F8D70104  LDR           r0,[r7,#0x104]
    0x000090F8 2800      CMP           r0,#0x00
    0x000090FA D0FA      BEQ           0x000090F2
    

    (couldn't locate the c/asm code for this in the sources so far).

    Also to note, sometimes code does hit the break point at 293, and lines up to 307, but mostly it doesn't go beyond 273. We are observing it going to the loop anywhere between above mentioned code lines (293 - 307).

    uint32_t softdevice_handler_init(nrf_clock_lfclksrc_t           clock_source,
                                     void *                         p_ble_evt_buffer,
                                     uint16_t                       ble_evt_buffer_size,
                                     softdevice_evt_schedule_func_t evt_schedule_func)
    {
        uint32_t err_code;
    
        //SD_HANDLER_LOG_INIT();
    
        // Save configuration.
    #if defined (BLE_STACK_SUPPORT_REQD)
        // Check that buffer is not NULL.
        if (p_ble_evt_buffer == NULL)
        {
            return NRF_ERROR_INVALID_PARAM;
        }
    
        // Check that buffer is correctly aligned.
        if (!is_word_aligned(p_ble_evt_buffer))
        {
            return NRF_ERROR_INVALID_PARAM;
        }
    
        mp_ble_evt_buffer     = (uint8_t *)p_ble_evt_buffer;
        m_ble_evt_buffer_size = ble_evt_buffer_size;
    #else
        // The variables p_ble_evt_buffer and ble_evt_buffer_size is not needed if BLE Stack support
        // is not required.
        UNUSED_PARAMETER(p_ble_evt_buffer);
        UNUSED_PARAMETER(ble_evt_buffer_size);
    #endif
    
        m_evt_schedule_func = evt_schedule_func;
    
        // Initialize SoftDevice.
    #if defined(S212) || defined(S332)
        err_code = sd_softdevice_enable(clock_source, softdevice_fault_handler, ANT_LICENSE_KEY);
    #else
        err_code = sd_softdevice_enable(clock_source, softdevice_fault_handler);
    
  • sd_softdevice_enable(clock_source, softdevice_fault_handler); appears to be a system call, and is part of the softdevice, and so is the asm code (loop). the source code of this part is probably not available to us (?) or is it? I see xPSR:ISR = 11, so the system is still within the system call context while looping.

Related