NRF_FAULT_ID_APP_MEMACC invalid memory access in Softdevice

Hi

I'm wrkig with nRF5 Software Development Kit v17.0.2 and BLE Mesh. When the device is running, after some hours of operation, the NRF_FAULT_ID_APP_MEMACC is getting triggered. Is there a possibility to see, which function is causing this call? I log this entry in flash to read out after soem hours, because I can't reproduce this in debug mode (or maybe I should wait longer).

Is the address of the function which is triggering an inavlid memory acces in the pc variable?

Parents
  • I was able to log the hard fault address: 165554 dez = 0x286B2

    I had some functions included with CRITICAL_REGION_ENTER(); and CRITICAL_REGION_EXIT();

    Could this be the issue?

    I had the instruction around a copy of a ADC value from the DMA, but this is not needed becase the nRF52840 will do a int copy in 1 thick, am I right?

    int16_t value;
    CRITICAL_REGION_ENTER();
    value = m_adc_ntc;
    CRITICAL_REGION_EXIT();

Reply
  • I was able to log the hard fault address: 165554 dez = 0x286B2

    I had some functions included with CRITICAL_REGION_ENTER(); and CRITICAL_REGION_EXIT();

    Could this be the issue?

    I had the instruction around a copy of a ADC value from the DMA, but this is not needed becase the nRF52840 will do a int copy in 1 thick, am I right?

    int16_t value;
    CRITICAL_REGION_ENTER();
    value = m_adc_ntc;
    CRITICAL_REGION_EXIT();

Children
  • Unfortunately this was not the Bugfix, I had a second device with the same hard-fault address without this CRITICAL_REGION_ENTER / EXIT call.

    Update:

    Could it be that the PA/LNA driver of the nRF21540 cause this problem? How could this be tested? Is there a possibility to change the PA/LNA driver config to another priority or how can I check if this driver cause the hard fault or not?

    I have only this call:

    static mesh_pa_lna_gpiote_params_t m_pa_lna_params =
    {
    	/**< Low Noise Amplifier configuration */
    	.lna_cfg = {
    		.enable = 1,
    		.active_high = 1,
    		.gpio_pin = ANT_RX_EN
    	},
    	/**< Power Amplifier configuration */
    	.pa_cfg = {
    		.enable = 1,
    		.active_high = 1,
    		.gpio_pin = ANT_TX_EN
    	},
    	.ppi_ch_id_set = LNA_PPI_CH_ID_SET,
    	.ppi_ch_id_clr = LNA_PPI_CH_ID_CLR,
    	.gpiote_ch_id = LNA_GPIOTE_CH_ID
    };
    
    static ble_opt_t ble_pa_lna_opts =
    {
    	.common_opt = {
    		.pa_lna = {
    			/**< Power Amplifier configuration */
    			.pa_cfg = {
    				.enable = 1,
    				.active_high = 1,
    				.gpio_pin = ANT_TX_EN
    			},
    			/**< Low Noise Amplifier configuration */
    			.lna_cfg = {
    				.enable = 1,
    				.active_high = 1,
    				.gpio_pin = ANT_RX_EN
    			},
    			.ppi_ch_id_set = LNA_PPI_CH_ID_SET,
    			.ppi_ch_id_clr = LNA_PPI_CH_ID_CLR,
    			.gpiote_ch_id = LNA_GPIOTE_CH_ID
    		}
    	}
    };
    
    err_code = sd_ble_opt_set(BLE_COMMON_OPT_PA_LNA, &ble_pa_lna_opts);
    mesh_pa_lna_gpiote_enable(&m_pa_lna_params);
    

  • I found this in the SDK release notes:

    nRF5 SDK v17.1.0
    ------------------------
    Release Date: August, 2021
     

    - NRFFOSDK-13607: Reduced the Radio IRQ priority in the Radio Test example
      when nRF21540 support is enabled, to avoid potential deadlock.

  • An Update to the SDK v17.1.0 did the BugFix.

    can somebody please tell me the change in the SDK which is responsable to fix this bug?

    Which files are affected and which lines? Because I don't use the radio test example, but I do use the nRF21540 drivers.

    In the release notes I found this entry: NRFFOSDK-13607

    - NRFFOSDK-13607: Reduced the Radio IRQ priority in the Radio Test example
      when nRF21540 support is enabled, to avoid potential deadlock.

Related