I have an older TREK1000 dev kit (EVB1000 boards have a sticker showing 27/10/2014) and the firmware on the boards is 1.06. I recently downloaded your source code for the ST Micro and have ported it to our system, disabling the onboard ST Micro MCU. The version string in the newer source shows 2.10.
The code seems to be running and I can talk to the DW1000 via SPI but I seem to get continuous RX Timeouts. The status register looks to be $028000F3 (TX) then $02820003 (RX). It appears that the CLKPLL_LL bit is set - not sure if this is serious or not.
Anyway, first off - is there any problem running the v2.10 code on the older EVB1000 hardware? Is newer v2.10 code compatible with the older 1.06 FW (ie: is it a problem if a tag is v2.10 and the anchors are v1.06)? Finally, is it recommended and safe to flash the latest ARM binary on the older EVB1000 boards?
Hi ,
There is no problem to flash any revision of the board with old or new TREK1000 and EVK1000 software.
All TREK and EVK boards identical and that explains that we also have 1 schematic.
So you will be fine with flashing your 1.06 boards with the more recent 2.10. Note that today we have version 2.25.
You have ported 2.10 to your own processor . The timeouts , do they appear when communicating to a board with the same software loaded, or is that board on 1.06.
Software version 2.10 and 1.06 are not compatible, eg different API . For example In 2.10 the TWR method was changed from symmetric to asymmetric TWR.
Maybe a way forward is use version 2.25 for your trek and for your own design.
Thank you for your response - I did make some progress. Since I’ve been working with 2.10 source code, I continued with that and flashed all the EVB1000 boards with it and that helped. I am using your firmware as the anchors; my firmware (your code on my processor) as a tag. I seem to be getting further but when instance_calcranges() runs, all the values from the anchors are INVALID_TOF ($abcdffff).
When I set debug = 1 to monitor the system status, I see these 3 status/state values repeat. Any clues here?
I/O: status 0000820003, byte 0 4188
I/O: states 0000010000
I/O: status 0000806FF3, byte 0 4188
I/O: states 0000010000
I/O: status 00008000F3, byte 0 4188
I/O: states 0000010000
Firstly, can I ask you to look at our example API, and load for example 6a in 1 evb and 6b in the other (or 5a & 5b) . You will see that the 2 boards start ranging with each other. Then port the example to your processor and see if that still works. If not then please consult our debugging application note, APS022
A reason for timeouts could well be that you are getting timeouts because your processor may not be fast enough or is simply too fast (what MCU are you using?) , so when a frame is received on the responding device, the device cannot reply in time to send response.
Are you using DWM1000 for your own design? The problem could be related also to the different OTP configurations the TREK and DWM1000 have. For example TREK will have a certain antenna delay value in the OTP, while the DWM1000 would have none set (as this has to be set by the customers) This mismatch would cause time outs. So maybe deactivate everything related to the OTP memory, when initializing the DWM1000 modules. And try out with different antenna delay.
To cut the story short, you maybe should start by porting simple examples first, and make sure you work on his system. This will show you where the delays might be and how fast you may be able to go. And use APS022 for debugging if you run into troubles.
For background, we bought the TREK1000 with 4 EVB1000 boards. I disabled the onboard MCU on the Tag (via the six S2 dip switches) and ported your ST Micro code to our system. I had to change it a little to work with our SPI code and so on but it is essentially the same code running. We don’t have any DWM1000 yet - we’re still using the EVB in bypass mode. As such, I expect the calibration and everything to be the same and if, in theory, the same SW is running then the tag should “just work” so this is where I’m stuck. I don’t know enough about the system to know why the same code isn’t working on our system.
Our processor is a custom ASIC and is a dual core A9 running at 500MHz. I am running the high speed SPI at 8MHz. I have tried using the EVB1000 IRQ to trigger the ISR and I’ve tried a polling/sleep loop to check & run the ISR. Perhaps the examples you mentioned are simpler but I can’t seem to find them. Can you tell me where the 6a/6b (5a/5b) examples can be found?
Can you explain what you meant by our processor possibly being too fast? What would be affected and what would need to be slowed down?
I haven’t tried the other demos you suggested because the Coocox compiler is no longer available (I’m just downloading what should be a good alternative). Thus I continued with your main application demo, which should run just as well. I am now getting sporadic range measurements but not consistently so I may have timing issues in play. Basic Rx and Tx does seem to work though.