HardFault after GPIO PIN set to High on Custom Board

RE: HardFault after GPIO PIN set to High on Custom Board

Vidar Berg — Mon, 26 Sep 2022 08:02:52 GMT

I agree that it seems strange, but I can't think of any other explanations at this point. The fact that the pull-up helped indicates there is a small current leak shortly after you've set the pin high.

RE: HardFault after GPIO PIN set to High on Custom Board

Buli — Fri, 23 Sep 2022 15:36:16 GMT

could be, but I'm not sure.

But as I said, just setting the boot0 pin on STM with P0.12 doesn't trigger anything on STM side, to start the bootloader, where the uart from STM will be configured I need to reset the STM after setting boot0 to high..

RE: HardFault after GPIO PIN set to High on Custom Board

Vidar Berg — Fri, 23 Sep 2022 15:17:35 GMT

Could it be that the oscilloscope probe adds enough capacitance to keep the RX line high?

RE: HardFault after GPIO PIN set to High on Custom Board

Buli — Fri, 23 Sep 2022 14:30:46 GMT

[quote userid="4240" url="~/f/nordic-q-a/92128/hardfault-after-gpio-pin-set-to-high-on-custom-board/387695"]This confirms that there was "glitch" on the RX line. [/quote]

but not according to the oscilloscope.

The issue with the frame error belongs to the uart config (the STM bootloader required a parity bit. already solved.

But at the time where I set P0.12 to "1" the uart is not involved. So, why is the UART raising the APP_UART_COMMUNICATION_ERROR event?

´The issue is gone, but the reason is still not clear for me.

RE: HardFault after GPIO PIN set to High on Custom Board

Vidar Berg — Fri, 23 Sep 2022 12:35:55 GMT

This confirms that there was "glitch" on the RX line.

Framing errors usually means you are overflowing the receive buffer, which can be avoided by either increasing the DMA buffer size, or by enabling HW flow control.

Note that the app uart library does not support DMA buffers >1 byte. If you need larger buffers you can use the Libuarte - advanced UARTE driver.

RE: HardFault after GPIO PIN set to High on Custom Board

Buli — Fri, 23 Sep 2022 12:26:10 GMT

The issue is resolved, but now a framing error occurs when I receive more than 1Byte (same on the DK)

For me is the connection between P0.12 and the RX not clear and why a "1" has trigger an "break" condition on the RX

RE: HardFault after GPIO PIN set to High on Custom Board

Vidar Berg — Fri, 23 Sep 2022 11:06:47 GMT

Hm, that's strange. Please try to add the following line right after APP_UART_FIFO_INIT() to enable the internal pull-up on the RX line and see if it makes any difference:

    ...
    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);
    NRF_P0->PIN_CNF[RX_PIN_NUMBER] |= (GPIO_PIN_CNF_PULL_Pullup << GPIO_PIN_CNF_PULL_Pos);
    ...

RE: HardFault after GPIO PIN set to High on Custom Board

Buli — Fri, 23 Sep 2022 10:56:30 GMT

No activities on the RX Line.

RE: HardFault after GPIO PIN set to High on Custom Board

Vidar Berg — Fri, 23 Sep 2022 10:51:13 GMT

And is there any activity on the RX during that time?

RE: HardFault after GPIO PIN set to High on Custom Board

Buli — Fri, 23 Sep 2022 10:46:55 GMT

It takes 0,043sec (2752438 cycles at 64MHz)

RE: HardFault after GPIO PIN set to High on Custom Board

Vidar Berg — Fri, 23 Sep 2022 08:35:37 GMT

Thanks for the clarification. So the APP_UART_COMMUNICATION_ERROR event is triggered when you set the P0.12 output. Have you measured how long time it takes from when P0.12 is asserted until the error event is raised?

RE: HardFault after GPIO PIN set to High on Custom Board

Buli — Fri, 23 Sep 2022 08:09:15 GMT

[quote userid="4240" url="~/f/nordic-q-a/92128/hardfault-after-gpio-pin-set-to-high-on-custom-board/387613"]

Buli said:
Nothing on the UART happens here. I'am setting with this pin a the Bootloader PIN from STM on High.

Yes, but you indicated earlier that the error only happened when you configured this pin?

[/quote]

Not at Configuration...At the time where I set the P0.12 Pin to "1"

[quote userid="4240" url="~/f/nordic-q-a/92128/hardfault-after-gpio-pin-set-to-high-on-custom-board/387613"]

Buli said:
Yes, this is correct, but this this doesn't come from the RX Line itself.

It does come from the RX line, so we have to try to narrow down the problem somehow. With the scope traces, were you able to verify if both the nrf and stm are transmitting with the correct baudrate?

[/quote]

The Baudrate on both are ok. The uart communication works well in both directions. As I said, at the time where I set P0.12 to "1" the error occurs. At the time where I set P0.12 to "1" nothing happens on the RX/TX lines

RE: HardFault after GPIO PIN set to High on Custom Board

Vidar Berg — Fri, 23 Sep 2022 07:30:28 GMT

Hi,

[quote userid="117109" url="~/f/nordic-q-a/92128/hardfault-after-gpio-pin-set-to-high-on-custom-board/387608"]Nothing on the UART happens here. I'am setting with this pin a the Bootloader PIN from STM on High.[/quote]

Yes, but you indicated earlier that the error only happened when you configured this pin?

[quote userid="117109" url="~/f/nordic-q-a/92128/hardfault-after-gpio-pin-set-to-high-on-custom-board/387608"]Yes, this is correct, but this this doesn't come from the RX Line itself.[/quote]

It does come from the RX line, so we have to try to narrow down the problem somehow. With the scope traces, were you able to verify if both the nrf and stm are transmitting with the correct baudrate?

RE: HardFault after GPIO PIN set to High on Custom Board

Buli — Fri, 23 Sep 2022 06:54:27 GMT

HI Vidar,

[quote userid="4240" url="~/f/nordic-q-a/92128/hardfault-after-gpio-pin-set-to-high-on-custom-board/387598"]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.[/quote]

Yes, this is correct, but this this doesn't come from the RX Line itself.

[quote userid="4240" url="~/f/nordic-q-a/92128/hardfault-after-gpio-pin-set-to-high-on-custom-board/387598"]Does this mean the STM is powered on before the nRF has enabled the UART interface?[/quote]

Yes, the STM is ready before the uart_init functions runs.

[quote userid="4240" url="~/f/nordic-q-a/92128/hardfault-after-gpio-pin-set-to-high-on-custom-board/387598"]

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?

[/quote]

Nothing on the UART happens here. I'am setting with this pin a the Bootloader PIN from STM on High.

RE: HardFault after GPIO PIN set to High on Custom Board

Vidar Berg — Fri, 23 Sep 2022 05:07:38 GMT

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.

[quote userid="117109" url="~/f/nordic-q-a/92128/hardfault-after-gpio-pin-set-to-high-on-custom-board/387543"]the nrf ist waiting for 200ms before he starts with the second line in main() after the delay sommand.[/quote]

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

[quote userid="117109" url="~/f/nordic-q-a/92128/hardfault-after-gpio-pin-set-to-high-on-custom-board/387543"]Furthermore I don't see any edges with the oscilloscope on my RX PIN when I'am setting P0.12 1[/quote]

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?

RE: HardFault after GPIO PIN set to High on Custom Board

Buli — Thu, 22 Sep 2022 17:26:12 GMT

RTS/CTS are disabled, same strange event

RE: HardFault after GPIO PIN set to High on Custom Board

hmolesworth — Thu, 22 Sep 2022 16:04:10 GMT

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

RE: HardFault after GPIO PIN set to High on Custom Board

Buli — Thu, 22 Sep 2022 15:16:48 GMT

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.

RE: HardFault after GPIO PIN set to High on Custom Board

Vidar Berg — Thu, 22 Sep 2022 14:20:31 GMT

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.

RE: HardFault after GPIO PIN set to High on Custom Board

Buli — Thu, 22 Sep 2022 14:06:35 GMT

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.

RE: HardFault after GPIO PIN set to High on Custom Board

Vidar Berg — Thu, 22 Sep 2022 13:20:20 GMT

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.

RE: HardFault after GPIO PIN set to High on Custom Board

Buli — Thu, 22 Sep 2022 12:19:19 GMT

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?

RE: HardFault after GPIO PIN set to High on Custom Board

Vidar Berg — Thu, 22 Sep 2022 11:32:02 GMT

Hi,

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

RE: HardFault after GPIO PIN set to High on Custom Board

Buli — Thu, 22 Sep 2022 10:35:33 GMT

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.

RE: HardFault after GPIO PIN set to High on Custom Board

Vidar Berg — Thu, 22 Sep 2022 10:10:36 GMT

Hi,

So the error is triggered in uart_event_handle, and the error code appears to be NRF_ERROR_DATA_SIZE.

You can get the exact line number of where the error occurred if you build with the 'DEBUG' flag enabled.