Hello,
I’m working on a RTLS project and I’d like to know if it is possible to flash the DWUSB with my own code. I’m interested in a Single Way Ranging method and I read that you use the TWR in the DWUSB.
Thanks in advance.
Regards,
Dani
Yes, it is possible to program the DWUSB with your own code. In order to do so, we recommend using the Atmel SAM-BA In-system Programmer, which you can download from Atmel’s website (http://www.atmel.com/tools/atmelsam-bain-systemprogrammer.aspx). Once you have downloaded and set up SAM-BA, you will want to put the DWUSB into the SAM-BA bootloader mode. This can be done by plugging the DWUSB into your PC, and then sending the string “xbootload\r\n” to the first port associated with the DWUSB, which should be /dev/ttyACM0 on most systems. For example, you could do this in Ubuntu with the following terminal command:
Once the DWUSB is in the SAM-BA bootloader mode, you can perform the following steps in order to flash your binary onto the DWUSB:
- Start the SAM-BA executable you downloaded from Atmel’s website.
- In the initial window that pops up, you will want to select the port associated with you DWUSB, which again for most systems should be /dev/ttyACM0. Then, you will want to select the board type, which is at91sam4s4-ek. Then, click connect.
- From the “Flash” tab, select the new firmware file using the browse button next to the “Send File” button.
- Click “Send File”.
- When asked about locking regions 0-4, choose “No”.
- From “Scripts” dropdown, select “Boot from Flash (GPNVM1)”, and click “Execute”.
- Unplug and re-plug the DWUSB, which will then boot into the new firmware.
Please be careful if you do decide to run your own firmware on the DWUSBs. We obviously cannot guarantee proper functionality of the device when you start using your own firmware. Also, it is probably a good idea to implement a way to return to the SAM-BA bootloader mode in your own firmware to make sure that you do not get stuck in any particular firmware image. If at any point you would like to load our firmware back onto the device, the current firmware image can be found on our website (http://www.ciholas.com/products).
Good! Thank you very much for your response!
When I go through the exact procedure indicated, i get the following error:
Any ideas?
That is a bug with Atmel SMA-BA. From our experience, SAM-BA versions later than 2.13 have issues flashing our firmware on the DWUSBs. For future releases, we intend to provide our own bootloader to prevent relying on the SAM-BA, which should alleviate this issue, but in the meantime, we recommend double checking your SAM-BA to ensure you are using a version later than 2.13.
mblankenship mentions to have a way in the firmware to return to the SAM-BA bootloader mode to avoid getting stuck in a single firmware image, I am a little confused as to what this means, are we not able to send the bootload string to the serial port in order to flash a new firmware once we have flashed our own? If yes, how is the enabling of the bootloader option done? Also, the manual says that the XBOOTLOAD command is to be used in order to switch to the SAM-BA mode, is this equivalent to sending the bootload string to the serial port?
One last question, does the firmware have to have just one Python file that contains a main function, for example, just the RxDemo.py file?
I am sorry if these are all stupid questions
In general, for the DWUSB firmware to be updated, the device needs to be put in bootloader mode first.
For the standard firmware, this is performed by sending the string “xbootload” to the firmware.
In bridge mode, you need to send the bootload command [it’s not a string]. That command is described in the screenshot you sent. Please note that you’ll need to calculate the checksum of the SSP command for it to be accepted by the bridge mode.
The full command is the following byte array:
C1 FB 00 04 00 10 06 0011 D6 EF 02 DC (copied from the Bridge User Manual)
In order to put a DWUSB device that has bridge code on it into bootloader mode from command line, you can send the following command:
sudo echo -e "\xC1\xFB\x00\x04\x00\x10\x06\x00\x11\xD6\xEF\x02\xDC\r\n" > /dev/ttyACM0 (copied from the Bridge User Manual)
You are right. This command puts the device in bootloader mode (SAM-BA mode)
The firmware that’s installed on the DWUSB is always the same file and does not change; regardless of application.
The code that changes is the python script that drives the bridge firmware.
The python application can be as many or as few files as needed. It can have classes, structures, and can use all of python’s features and libraries.
Just make sure to include the Ciholas libraries that facilitate talking to the bridge code and help in operating the DW1000. Those libraries are stored in the ‘libs’ directory in the examples zip file.
You are encouraged to explore and modify those libraries to gain a better understanding of the way the bridge mode and the DW1000 are used.
I hope this helps answering your questions.
Thanks,
Jawad
Oh, so does that mean that in order to run the python scripts I do not need to change the firmware, just upload the new code? If so, how do you upload the code and does the device come preinstalled with any firmware or do you have to initially flash it with the bridge firmware file provided? Does the code simply run on our PC and just pass commands through the USB?
Again, sorry if these are all stupid questions, I am a beginner working with electronics and embedded systems, I just wanted to be sure about everything before proceeding. Thank you for your prompt responses!
That’s right.
The Python code is not uploaded anywhere. It is run directly from your PC (or Pi) and the commands are sent to the bridge code in real-time. The application code and logic lies in your Python script that drives the bridge code.
The device comes preloaded with the normal UWB firmware which is compatible with the CUWB server and does not provide low-level access to the DWUSB and its peripherals.
You’ll need to upgrade the firmware to the bridge-mode to get low-level access; but you’ll lose the CUWB server functionalities including the TDOA algorithm.
That’s exactly right. The bridge code basically ‘bridges’ the communication between your PC and the DWUSB hardware.
All the drivers and logic are inside the Python scripts that are interacting with the bridge code.
No no! They are all very valid questions!
Thanks,
Jawad
Thank you very much!
I have been getting the low level initialization error as well, I am on an Ubuntu system, what is the workaround for this?
I tried the 2.16 version, the 2.13 version is not available
We’ve had this issue before and it seems to be a bug with the SAM-BA programming application.
The only workaround we’ve had is to try to use another computer to perform the firmware update process.
Are you updating to the bridge firmware or to the regular Ciholas firmware?
If you’d like to update to the recent Ciholas firmware, you can use the Device Firmware Update (DFU) utility from the website.
Thanks,
Jawad
Sorry this question is not related to the DWUSB directly, I was interested in developing my own firmware, would anybody know any resources for learning how to program the Atmel ATSAM4S4AA 32-bit ARM Cortex-M4 RISC and also how to go about learning the firmware development in general?
The USB connection on the DWUSB is directly connected to the on-board SAM4S, so developing custom firmware is possible.
A good starting point into programming the SAM processor would be the official datasheet and technical documents. You can also consult with the Atmel forums for additional questions.
This forum is only dedicated to hardware and software that’s officially provided by Ciholas. We will not be able to provide support for uses of the hardware outside that scope.
Thanks,
Jawad
Thank you very much for your help once again