DecaRangeRTLS ARM source code operation error

I’ve successfully compiled and loaded the DecaRangeRTLS ARM source code into my four EVB1000 boards and set their SW1 as Tag0, Anchor0, Anchor1, and Anchor2 modes respectively.

However, the Anchor0 LCD only shows “DecaRangeRTLS L2 Anchor:0” instead of “DecaRangeRTLS L2 T0 AxTx: r.rr m”.

The code is Ver.2.25mx TREK. Is it a version issue? Is anyone else also facing this problem?

Hi Dwacky,

The EVB1000 you used to load TREK Software was that original a EVK1000?
If so, than it might be just a S1 dip switch setting which is not consistent with the other boards.
The functions of the S1 are depending if it is TREK or EVK SW on teh boards.
Please see TREK User Manual fort he S1 Dip switch settings
/Leo

Hi Leo. Thanks again for the help.

I set the S1’s as above which is from the TREK1000 user manual.

The EVB1000 boards I purchased are either from TREK1000 or EVK1000. I do not remember which is from which now.

The software I loaded is a CubeMX generated code which I generated by following the “Upgrading EVB1000 to latest software IDE” manual, but I also enabled USART1 as Synchronous mode to use printf but I don’t think this matters.

After importing the generated code in ST Workbench, I copied application, compiler, decadriver, usb, and port files from the “DecaRangeRTLS_ARMCubeMx_2p25” project into my project.

I read the “DecaRangeRTLS ARM Source Code Guide” and am currently debugging the “instance_tag” code’s “switch(inst->testAppState)” cases.

Is there anything wrong with what I have done? Or do you suggest keep debugging thru the instance state machine code?

Hi Dwacky,

Could you maybe just load the the TREK .bin file , the already compiled SW on the boards, to confirm that the boards are ok? Its called DecaRangeRTLS_ARMCubeMxrev2p25.bin which is part of the zip file the TREK UM is part of.
The physical difference between a TREK and EVK board is that the TREK boards would have a white sticker under the S1 switches while the EVK board has not.

Hi Leo,

I programmed and verified the .bin file via the ST-Link Utility, and it works well with both TREK boards and EVK boards. So it doesn’t seem to be a board or hardware issue. I assume somewhere probably is wrong in the instance code.

I put some printf lines into the “switch (inst->testAppState)” cases of instance_tag.c and figured out that it only executes the TA_TX_WAIT_CONF case over and over after executing TA_INIT, TA_TXBLINK_WAIT_SEND, TA_RX_WAIT_DATA(RTLS_DEMO_MSG_RNG_INIT), TA_TXE_WAIT, and TA_SLEEP_DONE cases. I had one TAG and one ANCHOR powered up.

I haven’t put enough time into debugging after the weekends. I’ll let you know if I find something more.

Hi Again,
TA_TX_WAIT_CONF means the IC is waiting for the confirmation that the message transmission has completed. (TX done).

You could check the status and states registers (0xF, 0x19) when the device is not behaving as you expect. See APS022 our trouble shooting application note.

Also make sure you wait for TX done after sending before enabling RX, and similarly wait for RX to finish (either after frame reception or error) before re-enabling the RX.

See for information also the example API document and ARM DW1000_Software_API_Guide_rev2p7.pdf (1.5 MB)
source code description.

Leo