HardFault after GPIO PIN set to High on Custom Board

[Buli]

Hi,

on my Custom Board I'am setting P0.12 to High triggered by a BLE notification (NUS). I'am here using the BLE Uart Example (S112, pca10040). The Custom Board's nrf52832 DCDC Pin is not connected

The Problem is, that on my Custom Board the System goes direct in the Hard Fault on the nrf52 DK not. Is there something in for P0.12 in use somewhere else?

P0.12 is bounded to an STM32 MCU's boot0 Pin with a external 10k pulldown.

if (p_evt->type == BLE_CTRL)
{

if (p_evt->params.rx_data.p_data[0]==0xFA)
{ // Bootloader Pattern1
m_ctrl=1;
nrf_gpio_pin_write(12, 1);
nrf_gpio_pin_write(11, 0);
for (uint16_t ts=0;ts<4000;ts++){}
nrf_gpio_pin_write(11, 1);

}


if (p_evt->params.rx_data.p_data[0]==0xFB)
{ // Reset
m_ctrl=0;
nrf_gpio_pin_write(12, 0);
nrf_gpio_pin_write(11, 0);
for (uint16_t ts=0;ts<4000;ts++){}
nrf_gpio_pin_write(11, 1);

}

[Buli]

The section for 0xFB works on both..custom and DK board

The section for 0xFA not it goes to the hard fault direct after nrf_gpio_pin_write(12, 1) on the custom board. On the scope I can see, that the GPIO is set on high. It seems, that something else are triggered by setting P0.12 to high, but what and why is it different to the DK board, where P0.12 aren't in use.

This is the init snipped for the GPIO's

nrf_gpio_cfg_output(11);
nrf_gpio_cfg_output(12);
nrf_gpio_pin_set(11);
nrf_gpio_pin_clear(12);

[Vidar Berg]

Hello,

I can't think of any obvious reasons for the hardfault based on the information given here. I also think it's strange that you only see it on your custom board but not on the DK.

As a start, can you post a screenshot of the call stack window after the program has entered the fault handler. Alternatively, if you can enable the HardFault handling library and post the log output here.

Best regards,

Vidar

[Buli]

Hi Vidar,

it was triggered by the uart event handler

void uart_event_handle(app_uart_evt_t * p_event)
{
    static uint8_t data_array[BLE_NUS_MAX_DATA_LEN];
    static uint8_t index = 0;
    uint32_t       err_code;

    switch (p_event->evt_type)
    {
        case APP_UART_DATA_READY:
            UNUSED_VARIABLE(app_uart_get(&data_array[index]));
            index++;

							if ((((data_array[index - 2] == '\n') && (data_array[index - 1] == '\r')) ||
									(index >= m_ble_nus_max_data_len)) || (index>0 && m_ctrl==1))
								//if(index >0)
							{
							 
								if((index >1) || (index>0 && m_ctrl==1))
									{
											//NRF_LOG_DEBUG("Ready to send data over BLE NUS");
											//NRF_LOG_HEXDUMP_DEBUG(data_array, index);

											do
											{
													uint16_t length = ((uint16_t)index);
													err_code = ble_nus_data_send(&m_nus, data_array, &length, m_conn_handle);
													if ((err_code != NRF_ERROR_INVALID_STATE) &&
															(err_code != NRF_ERROR_RESOURCES) &&
															(err_code != NRF_ERROR_NOT_FOUND))
													{
															APP_ERROR_CHECK(err_code);
													}
											} while (err_code == NRF_ERROR_RESOURCES);
									}

									index = 0;
									
							}
            break;

        case APP_UART_COMMUNICATION_ERROR:
            APP_ERROR_HANDLER(p_event->data.error_communication);
            break;

        case APP_UART_FIFO_ERROR:
            APP_ERROR_HANDLER(p_event->data.error_code);
            break;

        default:
            break;
    }
}

Why this is happening, when I sent from BLE to the device? The UART shouldn't be involved here.

static void nus_data_handler(ble_nus_evt_t * p_evt)
{

    if (p_evt->type == BLE_NUS_EVT_RX_DATA)
    {
        uint32_t err_code;

//        NRF_LOG_DEBUG("Received data from BLE NUS. Writing data on UART.");
//        NRF_LOG_HEXDUMP_DEBUG(p_evt->params.rx_data.p_data, p_evt->params.rx_data.length);

        for (uint32_t i = 0; i < p_evt->params.rx_data.length; i++)
        {
            do
            {
                err_code = app_uart_put(p_evt->params.rx_data.p_data[i]);
                if ((err_code != NRF_SUCCESS) && (err_code != NRF_ERROR_BUSY))
                {
                    //NRF_LOG_ERROR("Failed receiving NUS message. Error 0x%x. ", err_code);
                    APP_ERROR_CHECK(err_code);
                }
            } while (err_code == NRF_ERROR_BUSY);
        }
//        if (p_evt->params.rx_data.p_data[p_evt->params.rx_data.length - 1] == '\r')
//        {
//          while (app_uart_put('\n') == NRF_ERROR_BUSY);
//        }
					
				
    }
		
		if (p_evt->type == BLE_CTRL)
		{
			uint32_t err_code;

			
			if (p_evt->params.rx_data.p_data[0]==0xFA)	
			{ // Bootloader Pattern1
				m_ctrl=1;
		  	nrf_gpio_pin_write(12, 1);
				for (uint16_t ts=0;ts<4000;ts++){} 
				nrf_gpio_pin_write(11, 0);
				for (uint16_t ts=0;ts<4000;ts++){} 
				nrf_gpio_pin_write(11, 1);
			
			}
		
						
			if (p_evt->params.rx_data.p_data[0]==0xFB)	
			{ // Reset
				m_ctrl=0;
				nrf_gpio_pin_write(12, 0);
				for (uint16_t ts=0;ts<4000;ts++){} 
				nrf_gpio_pin_write(11, 0);
				for (uint16_t ts=0;ts<4000;ts++){} 
				nrf_gpio_pin_write(11, 1);
			
			}
			

				
			
		}
		

}

The nrf_gpio_pin_write(12, 1); is raising the uart event handler.

One important info, from 100 try's 1-2 times works. 

[Vidar Berg]

Hi,

Do you see the same if you ignore UART communications errors by commenting the APP_ERROR_HANDLER() line in APP_UART_COMMUNICATION_ERROR?

[Buli]

Hi Vidar,

it's not going into an error handler, and it works, but not sure why.

The most strange thing is, why the uart_event_handle() is called, when I'm setting P0.12 within the nus_data_handler() this happens only with this PIN?

[Vidar Berg]

Hi,

What is the pinout for your UART interface? There must be something that cause the UART to receive invalid data when you assert pin 12.

[Buli]

Hi Vidar,

#define RX_PIN_NUMBER 6
#define TX_PIN_NUMBER 8

static void uart_init(void)
{
    uint32_t                     err_code;
    app_uart_comm_params_t const comm_params =
    {
        .rx_pin_no    = RX_PIN_NUMBER,
        .tx_pin_no    = TX_PIN_NUMBER,
        .rts_pin_no   = RTS_PIN_NUMBER,
        .cts_pin_no   = CTS_PIN_NUMBER,
        .flow_control = APP_UART_FLOW_CONTROL_DISABLED,
        .use_parity   = false,
#if defined (UART_PRESENT)
        .baud_rate    = NRF_UART_BAUDRATE_115200
#else
        .baud_rate    = NRF_UARTE_BAUDRATE_115200
#endif
    };

    APP_UART_FIFO_INIT(&comm_params,
                       UART_RX_BUF_SIZE,
                       UART_TX_BUF_SIZE,
                       uart_event_handle,
                       APP_IRQ_PRIORITY_LOWEST,
                       err_code);
    APP_ERROR_CHECK(err_code);
}

It is the code from the example. I just swapped the RX and TX Pin

With the Scope I check the RX, whether there is something happening while I set P0.12 to high, but there is nothing.

[Vidar Berg]

I suggest you print a log message every time you get APP_UART_COMMUNICATION_ERROR to see how frequent it occurs. It would also be better if you could capture the packet that led to this event.

I guess there may be a glitch when the STM configures its TX pin during bootup.

[Buli]

Hi Vidar,

the nrf ist waiting for 200ms before he starts with the second line in main() after the delay sommand.

Furthermore I don't see any edges with the oscilloscope on my RX PIN when I'am setting P0.12 1

Therefore I'am wondering why and from where this event is triggered.

[hmolesworth]

Perhaps hardware bus contention with RTS or CTS pin numbers fighting against STM or other connection with incorrect polarity which can lead to a fault; check by disabling RTS and CTS pins in config

[Buli]

RTS/CTS are disabled, same strange event 

[Vidar Berg]

Hi,

The UART peripheral will raise this event when an Error condition is detected on the RX pin, and from the  screenshot you posted we can see it detected a BREAK condition.

Buli said:

the nrf ist waiting for 200ms before he starts with the second line in main() after the delay sommand.

Does this mean the STM is powered on before the nRF has enabled the UART interface?

Buli said:

Furthermore I don't see any edges with the oscilloscope on my RX PIN when I'am setting P0.12 1

What exactly happens when you set configure P0.12? Will there be any UART communication between the nrf and stm if you don't configure it?