I am porting the firmware example “EX_01A SIMPLE TX v1.2” to another uC. I am using the Rev 2.14 example collection. I have got it to the point where the DW1000 claims that it finished sending the example TX (I get the TXFRS flag in SYS_STATUS). But I cannot observe any RF power when sniffing the antenna. Using the same 8GHz detector I can observe the RF of the POLL being sent by an EVB V3.05 TAG.
The DWM1000 module I have is from 2014. From OTP, the part ID is 0xCCA25A15 and the Lot ID is 0x01AA2145. The DEV_ID register reports 0xDECA0130. I’m wondering if I could be having a chip revision errata problem. I do notice that some of the register reset values differ from the user manual V2.11.
1 Like
Hi,
EVK SW 3.05 and the example code have 2 different APIs and are therefore incompatible.
I would recommend that you use a simple TX example on one side and simple RX on the other (e.g. your micro).
And debug the easy/simple examples 1st and then work on porting TWR to their platform.
We also have TWR examples in the examples package.
As you probably have 2 EVBs, You can also use PC decaranging to listen to your design using the listener function . See PC Decaranging User manual.
The date on the chip could not be issue as there have been no change i.e DWM1000s produced in 2014 and DWM1000 produced today are identical .
/leo
Hi
And also, if you use for example… example 6a on your design and 6b on the EVB1000, your design would be fine once you see the distance between the 2 nodes on the display of the EVB1000.
Check the API guide for the details
/Leo
Thank you for your replies.
I am keeping the EVBs as I received them. They represent working examples of known-good hardware and firmware.
I had previously ported a Python RX example to test receiving on my hardware. I could RX the various EVB transmissions so I knew my hardware/firmware was working. I’ve switched to porting the simple ARM/GNU examples you mentioned so I can get some more experience making the DW1000 do its thing(s). Trying to un-twist the EVB application was frustrating to say the least.
My current puzzlement is why the DW1000 status indicates a TX has completed but I see no indication on my RF detector (1 to 8000 MHz). I can clearly detect the EVB POLL TX, weak as it is. Looking the other way, how could I prevent a “successful” TX from being observable at the chip antenna? The TX power control register should be set to a fairly strong output level (above Part 15 limits). The various TX control registers seem (I dump them to a serial port) to have correct values, a valid TX channel number for example.
For the TX test I am using the TX message and channel settings from the example EX-01A. The values from the example look OK and they seem to cause the chip register configuration functions to do the right things.
I am going to port the simple RX example and see if I can receive the EVB TAG POLL by changing the channel configuration values.
FYI, my target processor is a PIC18F87K22 running at 64 MHz. Firmware is compile PIC C89. I had to write my own 64-bit math routines as PIC C89 doesn’t support long longs or doubles. I would like to get permission to replace the PIC with an ARM Cortex M4, but that is a different project. I think I already spent more time making the PIC compiler work for the DW1000 than I would have spent on a new PCB and code porting. Sigh.
John Rose
Cervis Inc.
Hi,
Also note that the example code is based on the 32-bit MCU on the EVB, being a STM32F105RC.
This might mean that the 2 SPI speeds are not in sync and some timing has to be adjusted.
And correct me when I’m wrong, but your processor is also 8-bit , versus the 32bit on the EVB.
We have an application note for porting to a 8-bit CPU, See APS019, which is available from our website (and then application-notes —>> UWB Systems.
And while you’re you should maybe download APS022 also, our debugging application note.
Regards
/Leo
APS022 provides some useful debug info. I’ll watch the TX state machine to see if it follows the required sequence. I’m not sure if I will be able to track all the states in real time as my fast SPI clock is only 4 MHz due to the physical properties of the SPI wiring. I have to limit the SPI signal slew rates to minimize RF emissions.
APS019 has some good things to consider, but they are not the problem.
I do have some of the STM32F103 “blue pills” and a working firmware IDE I can use if I get desperate. When I first started on this I did state that everyone use an ARM, not a PIC, for good reasons. But that is another battle.
JRR
Now that I have documentation for the SYS_STATE register I have checked it.
After I write the TXSTRT bit is SYS_CTRL I read SYS_STATE. Both PMSC_STATE and TX_STATE are IDLE, and they stay that way.
Here’s a dump of the DW1000 registers:
DWM1000 Test V99.99.98 YMD19:02:05 PCB SN: 7f:ff:00 uC==87K22 ROMEUI: 7d:00:22:ea:82:60:3b:9c
DecaWave detected: DW1000 Version: 03 Revision: 00
DevIDreg00:0000: DECA0130
EUI64reg01:0000: FFFFFFFF00000000
PANADRreg03:0000: FFFFFFFF
SYSCFGreg04:0000: 00441200
SYSTIMEreg06:0000: 029EDC7C00
TXFCTRLreg08:0000: 00000A000C
RXFWTOreg0C:0000: 0000
SYSCTRLreg0D:0000: 00000000
SYSMASKreg0E:0000: FFFFFFFF
SYSSTATreg0F:0000: 0000800003
RXFINFOreg10:0000: 00000000
SYSSTATErg19:0000: 0000010000
TXPWRreg1E:0000: 1F1F1F1F
CHANreg1F:0000: 4A7A0022
LDOTUNEreg28:0030: 88888888
FSPLLreg2B:0007: 08400508
LDETHRreg2E:0000: 0000
PMSCCT0reg36:0000: F0300200
PMSCCT1reg36:0004: 81020000
PMSCSNZreg36:000C: 40
PMSCTXFreg36:0026: 0B74
PMSCLEDreg36:0028: DE000020
PartID: CCA25A15
LotID: 01AA2145
LDOtunelow: 88888888
LDOtunehigh: 00000008
VBATs: 0000EDAA
VTEMP: FFFFFF86
ANTdelays: 00000000
XTLtrim: 00000111
After a lot of head scratching and careful line-by-line review of the ported code I found an extra soft reset function call that was messing something up. With that removed rapid progress has been made and I have my TAG and ANCHOR talking.
I still have some more work-arounds to do to get full range measurement functionality per the examples, but the RF link is good.
Thanks for your support!