IRQS bit from SYS_STATUS high and no Interrupt firing

Wireless Connectivity Ultra-Wideband
, ,
1

Hello.

I’ve been checking dozens of registers, lines, source code, etc, and I do not find what is wrong.

The interrupt is set in the DW1000:

[code] /* Configure DW1000. See NOTE 3 below. */
dwt_configure(&config);

/* Register RX call-back. */
dwt_setcallbacks(&tx_conf_cb, &rx_ok_cb, &rx_to_cb, &rx_err_cb);

/* Enable wanted interrupts (TX confirmation, RX good frames, RX timeouts and RX errors). */
dwt_setinterrupt(DWT_INT_TFRS | DWT_INT_RFCG | DWT_INT_RFTO | DWT_INT_RXPTO | DWT_INT_RPHE | DWT_INT_RFCE | DWT_INT_RFSL | DWT_INT_SFDT, 1);[/code]

The GPIOs clock is enabled, the interrupt line is read by the STM32F103C8

[code] /* GPIO Ports Clock Enable */
__HAL_RCC_GPIOC_CLK_ENABLE();
__HAL_RCC_GPIOD_CLK_ENABLE();
__HAL_RCC_GPIOA_CLK_ENABLE();
__HAL_RCC_GPIOB_CLK_ENABLE();

/*Configure GPIO pin : DW_IRQn_Pin */
GPIO_InitStruct.Pin = DW_IRQn_Pin;
GPIO_InitStruct.Mode = GPIO_MODE_IT_RISING;
GPIO_InitStruct.Pull = GPIO_PULLDOWN;
HAL_GPIO_Init(DW_IRQn_GPIO_Port, &GPIO_InitStruct);[/code]

I transmit in immediate mode and check sys_status and tx_fctrl:

[code] /* Write frame data to DW1000 and prepare transmission. See NOTE 4 below./
dwt_writetxdata(sizeof(tx_msg), tx_msg, 0); / Zero offset in TX buffer. /
dwt_writetxfctrl(sizeof(tx_msg), 0, 0); / Zero offset in TX buffer, no ranging. */

    /* Start transmission. */
    dwt_starttx(DWT_START_TX_IMMEDIATE);
    TXFCTRLreg = dwt_read32bitoffsetreg(TX_FCTRL_ID, 0);

    sysSTUSreg = dwt_read32bitoffsetreg(SYS_STATUS_ID, SYS_STATUS_OFFSET);[/code]

Check the TX_FCTLR and the SYS_STATUS. In the TX_FCTLR is indicated that 14 chars has been transmitted. In the SYS_STATUS, the IRQS bit is high, and all the TX flags are high as well (The last byte is 0xF3), but the IRQn line is not set to high. I’ve tried to use pull down, pull up, and no pull, and the result is the same.

By software I forced the GPIO associated to IRQn to be high and all the software is correctly done. The interrupt handler calls to dw_isr, and finally to tx_conf_cb().

I’ve changed the DWM1000 in order to discard this particular IC malfunction.

So, everything should be ok (it is basically ex_03d_tx_wait_resp_interrupts ported to HAL and Cubemx) but the IRQn line do not go high.

¿Does anybody have a hint about what is happening?

Thanks in advance, regards.

2
  • make sure that SPI connection work properly. (see also chapter 3 in debugging application note APS022)
  • You are using CubeMX for creating stm32 uC configuration so make sure that processor work at maximum available frequency.
  • SPI in stm32 has some problems with buffers (when using HAL libraries). make sure that what is send via SPI is what you receive form buffers
    /L
3

Thank you Leo for your help.

  • The SPI is working. Thanks for pointing the chapter 3 of APS022. I read the same sequence of integers than I wrote in register 0x21.

[code]volatile uint8 dataA[20] = {19, 18, 17, 16, 15, 14, 13, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 11};
volatile uint8 dataB[20];

dwt_writetodevice(0x21, 0, 20, &dataA[0]);
dwt_readfromdevice(0x21, 0, 20, &dataB[0]);[/code]

  • This is probably where I have more doubts. In CubeMX I get 72 MHz using a HSE of 8 MHz (it is the cristal I have) and a PLLMUL of 9. I send a image of the clock configuration in Cube. I think is correct, but not 100% sure:
    [attachment=35]

  • I’ve checked the transmit buffer doing the following:

[code] /* Write frame data to DW1000 and prepare transmission. See NOTE 4 below./
dwt_writetxdata(sizeof(tx_msg), tx_msg, 0); / Zero offset in TX buffer. /
dwt_writetxfctrl(sizeof(tx_msg), 0, 0); / Zero offset in TX buffer, no ranging. */

    dwt_readfromdevice(0x09, 0, sizeof(tx_msg), &dataB[0]);[/code]

In the manual is said that reading 0x09 register is not supported because can corrupt data when TX. In a step by step debugging I think that this won’t be the case. The buffer read is correct. It has the original data, plus the two CRC bytes are calculated.

So, I can not find the reason why the IRQn is not set high. Reading other thread, someone was concerned about having enough current capacity in the power. Perhaps this is the case. I get 3.3V from the MCU. The DWM1000 consumption can be greater than the supported by the MCU so the signal can not be set high.

I have to make some arrangement to power DWM1000 from another source.

Thanks again Leo.

4

Thank you. I got the problem. It was a faulty soldering in the IRQn line. This is one of these strange cases where the problem was NOT the software, but the hardware :slight_smile: . Nevertheless I’ve learned a lot of debugging applications. Thanks Leo and Dirk.