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

HARDFAULT in mesh SDK ble_mesh_v0.9.1-Alpha access.c

I have the mesh serial example working with nRF51-DK (nRF51422). I am now trying to run the same code, via the nRF51-DK debug port, to a nRF51822 QFAC (32Mb) based board. It downloads and runs up to the following line where I get a HARDFAULT:

static void access_state_clear(void)
{
    memset(&m_model_pool[0], 0, sizeof(m_model_pool));

A break at this line shows the m_model_pool memory is allocated (it's static anyway) and accessible. Stepping over this line gives a HARDFAULT. What might be causing this?

The nRF51-DK (nRF51422) and the nRF51822 QFAC have the same memory maps so I am using the same build settings.

Simon

Parents
  • Hi Simon,

    The Bluetooth mesh stack operates in a SoftDevice Timeslot to allow running both the mesh stack and the SoftDevice concurrently. This causes a problem during debugging, though. A timeslot is a window of time that can be requested from the SoftDevice where it hands over the ownership of the radio (and some other peripherals). If the application doesn't yield the timeslot before its end, the SoftDevice will trigger an assert/HARDFAULT, since its internal scheduler cannot meet its deadlines any more and is left in an undefined state.

    That's what's happening when you're stepping your code. When doing a step, the debugger re-enables the CPU, the TIMER0 interrupt fires and the SoftDevice triggers the assert. To circumvent this, you can use "step instruction" instead of the normal "step".

    When you get an assert or HARDFAULT, the examples should print the program counter over RTT. To get the file and line, use the addr2line utility provided with the GNU toolchain(s).

    addr2line -a <program counter value> -e <path to my_program.elf>
    

    Make sure you've compiled your program with debugging symbols.

    Please note that there is a bug in the the serial_bearer.c, where the packet buffers needs to be word aligned. See fix in the diff below.

    /********** Static variables **********/
    
    +/* Buffers must be word-aligned to the largest possible serial packet. */
    +#define RX_BUFFER_SIZE ALIGN_VAL(sizeof(serial_packet_t) + sizeof(packet_buffer_packet_t), WORD_SIZE)
    +#define TX_BUFFER_SIZE ALIGN_VAL(sizeof(serial_packet_t) + sizeof(packet_buffer_packet_t), WORD_SIZE)
    -static uint8_t m_tx_buffer[sizeof(serial_packet_t) + sizeof(packet_buffer_packet_t)];
    +static uint8_t m_tx_buffer[TX_BUFFER_SIZE];
     static packet_buffer_t m_tx_packet_buf;
     static packet_buffer_packet_t * mp_current_tx_packet;
     static uint16_t m_cur_tx_packet_index;
     static uint16_t m_stored_pac_len;
    -static uint8_t m_rx_buffer[sizeof(serial_packet_t) + sizeof(packet_buffer_packet_t)];
    +static uint8_t m_rx_buffer[RX_BUFFER_SIZE];
    

    Best,
    Thomas

  • Thomas

    Thanks for the explanations. The word aligned fix has allowed me to get further. It's now hardfaulting when nrf_mesh_serial_init() is called. I have tracked this down to:

    uECC_VLI_API int uECC_generate_random_int(uECC_word_t *random,
                                              const uECC_word_t *top,
                                              wordcount_t num_words) {
    ...
            if (!g_rng_function((uint8_t *)random, num_words * uECC_WORD_SIZE)) {
    

    Are these any more data alignment problems I need to know about?

    Thanks

    Simon

Reply
  • Thomas

    Thanks for the explanations. The word aligned fix has allowed me to get further. It's now hardfaulting when nrf_mesh_serial_init() is called. I have tracked this down to:

    uECC_VLI_API int uECC_generate_random_int(uECC_word_t *random,
                                              const uECC_word_t *top,
                                              wordcount_t num_words) {
    ...
            if (!g_rng_function((uint8_t *)random, num_words * uECC_WORD_SIZE)) {
    

    Are these any more data alignment problems I need to know about?

    Thanks

    Simon

Children
No Data
Related