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]

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?

 

[Buli]

HI Vidar,

Vidar Berg said:

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.

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

Vidar Berg said:

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

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

Vidar Berg said:

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?

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

[Vidar Berg]

Hi,

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?

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?

[Buli]

Vidar Berg said:

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?

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

Vidar Berg said:

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?

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

[Vidar Berg]

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?

[Buli]

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

[Vidar Berg]

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

[Buli]

No activities on the RX Line.

[Vidar Berg]

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);
    ...