Software stucked on TA_TX_WAIT_CONF after POLL sending

Hello,
I have a custom PCB based on STM32L071 and I adapted DECARANGING software for it.
Blink transmission completes successfully, but after the case “TA_TXPOLL_WAIT_SEND” the software on TAG stucks on the “TA_TX_WAIT_CONF” step. In the terminal I get this:
DECAWAVE RANGE
TAG BLINK FFFFFFFF00000000
TA_TX_WAIT_CONF 9 m0 states 00040001 00800012
GOT RTLS_DEMO_MSG_RNG_INIT - start ranging -
TA_TX_WAIT_CONF 2 m0 states 00040001 00800012
RANGING WITH FFFFFFFF000000AA
TA_TX_WAIT_CONF 2 m0 states 00040001 02000012
TA_TX_WAIT_CONF 2 m0 states 00050c00 02000ff3
and after I continue to recieve this message:
TA_TX_WAIT_CONF 2 m0 states 00050c00 02000ff3

Please help me to solve that.
Thanks in advance.

in UM for DW1000 red about SYS_STATE and SYS_STATUS registers and understand how wait4response (delayed Rx) is working.
I think your SW is programming the Tx with delayed Rx, and then you get Rx prior SW could react to the Tx IRQ. This is the problem.

You can see that 00050c00 02000ff3 indicates, that you successfully have sent and received the frame, as the IRQ bit 0 is set.
See what is happening below:
00040001 02000012 <- chip is sending frame, i.e. Tx state

… because you are slow, you are missing here the status 020000f3 <- Tx only IRQ
… your sw expecting TX to be confirmed to go to the next state_machine state, but it cannot because it is slow and it has missed this IRQ.

00050c00 02000ff3 <- chips sent AND has received the frame, and the IRQ bit set .

You can see, that you stuck in the TA_TX_WAIT_CONF: that is because your Application is awaiting confirmation of the Tx, but you already have a reception of the frame from another side.
The software you are running is not developed to handle the situation above.

In this particular case, you have to either increase timings, that in TWR scheme your app would be able to react to the Tx IRQ, OR make the app work faster OR resolve the potential issues when you have this situation OR use another way to set up the Rx, only after getting the Tx IRQ.

If you are using the DecaRanging PC application, that application is very, very slow, and has developed to only work with two DW1000 based chips (without any other UWB activity in the air).
If you have overlapping UWB activity, say 3-rd Tag Tx randomly or another DR runnin in the same air-space, you can get the situation above, that while waiting for the Tx Done you got another unexpected Rx. And the application, which is not designed to handle such situations would get stuck.

Hi, thanks for the response.
Let me clarify a bit: I’m using the software downloaded from the decawave website, I just changed hardware definitions from stm32f103 to stm32l071. So I guess it should work without any changes, isn’t it?

That portable SW which you have downloaded is working with all limitations you have introduced, as you have changed:

Core: Cortex M3 to M0+
I/O interface: USB to UART <- perhaps this is your main problem.
MCU clock : 72MHz to 32MHz
SPI speed : instead 18MHz max you can do 8MHz or maybe less.

Please read what I wrote before and ask technical questions.
Regards

I’m not using USB or UART (uart is for printf only) and ranging procedure is going without commands from UART.
Could you please explain, why blink transmission is performing without the same issue?
In my case with slower MCU I have to increase timings, could you please let me know where required timings are defined?
Thanks in advance.

Sorry, I cannot read in between lines or guess what are you using or not.
You wrote that you are using Decaranging, this is a PC based application which is using USB-to-SPI to talk with DW chips.

I would suggest you to check with Decawave, they have a list of design partners, who can help you debug your project. https://www.decawave.com/partners/

I’ve read Decaranging (ARM) source code guide and there’s no any reference to a desktop software (except of disclaimer note). Basically when I work with DW1000 dev kits I don’t need the PC app too and all the ranging operations display on the LCD, so I just replaced LCD functions by “printf”.

I don’t need a debug session, I just need a quick help where I can change delay definitions.

Thanks.

Hello Alex,
Currently I replaced the MCU by STM32L431 instead of STM32L071 (72MHz clock and 18 MHz SPI).
Now I get another issue which I have not seen before.
In the function “inittestapplication(uint8 s1switch)” I successfully passed “if-statement”:
if(DWT_DEVICE_ID != devID) //if the read of device ID fails, the DW1000 could be asleep
{
port_wakeup_dw1000();
devID = instancereaddeviceid() ;
// SPI not working or Unsupported Device ID
if(DWT_DEVICE_ID != devID)
return(-1) ;
//clear the sleep bit - so that after the hard reset below the DW does not go into sleep
dwt_softreset();
}

then after:
result = instance_init();
if (0 > result) return(-1); // Some failure has occurred
I return “-1”
Inside the “instance_init();” function the error is get here:
result = dwt_initialise(DWT_LOADUCODE); -> result != 0

Dear,
What API are you using? One of our examples?
Can you do some trouble shooting yourself using our debug application note (attached)
APS022_Debugging_DW1000_based_products_systems_v1.3.pdf (721.0 KB)
/L

Hello Leo,
Thanks for the efforts. We successfully resolved our issue!

Hi Azmin
Would you mind sharing witht the forum what the issue was , how you solved it?
It would benifit possible a good few users.

Kind Regards & stay safe
Leo

1 Like

Hi Leo,
Sorry for the delay.
This topic solved my problem: