# Make USRP run w/o SW intervention **URL:** \ **Category:** GNU Radio\ **Created:** [September 27, 2011, 10:26pm UTC](https://www.ruby-forum.com/t/make-usrp-run-w-o-sw-intervention/212271 "2011-09-27T22:26:34Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\ **Post date:** [September 27, 2011, 10:26pm UTC](https://www.ruby-forum.com/t/make-usrp-run-w-o-sw-intervention/212271/1 "2011-09-27T22:26:34Z")
Hello Friends, My name is Reginald and I am an SDR enthusiast currently pursuing my latest project with the N210 box. I have the utmost respect for this hardware and hope to integrate it into my newest intellectual pursuit. My project is a box that sends and receives cellular SMS messages and with my expertise being mostly in FPGA I am tackling this venture by modifying the FPGA code. So far I have been successful implanting my HDL based cellular receiver in the FPGA after the dsp\_core\_rx module and a attaching my transmit directly to the DAC output pins, bypassing dsp\_core\_tx. However, it seems that the box cannot run standalone without software intervention because the ethernet IO is not free running and ADC and DAC clocks can be shut off by software. Furthermore, it seems running example programs such as rx\_samples\_to\_file overwrite SPI values programmed to AD9510 in the firmware burned onto the motherboard, for example, changing the divisors for the clocks to ADC and DAC. I confirmed this by probing the hardware. My project works when I run rx\_samples\_to\_file program to force the board to be active on receive and transmit, and also force the ethernet output to be active, which I have configured to send out some status messages so I can tell the demodulator is functioning. Is there any simple change I can make to the FPGA or firmware in order to have the box run without intervention, meaning all the SPI programming is handled by firmware, DAC/ADC clocks are on forever, and the ethernet output is continuously putting out the output I’ve wired it up for in the FPGA? Many thanks for any assistance on this matter. Reginald ---
**Author:** ![Reginald\_Cornwallic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/f14d63/32.png) [@Reginald\_Cornwallic](https://www.ruby-forum.com/u/Reginald_Cornwallic)\ **Post date:** [September 28, 2011, 12:04am UTC](https://www.ruby-forum.com/t/make-usrp-run-w-o-sw-intervention/212271/2 "2011-09-28T00:04:41Z")
On 09/27/2011 04:25 PM, Reginald Cornwallice wrote: > my transmit directly to the DAC output pins, bypassing dsp\_core\_tx. > be active on receive and transmit, and also force the ethernet output to be > active, which I have configured to send out some status messages so I can > tell the demodulator is functioning. > > Is there any simple change I can make to the FPGA or firmware in order to > have the box run without intervention, meaning all the SPI programming is > handled by firmware, DAC/ADC clocks are on forever, and the ethernet output > is continuously putting out the output I’ve wired it up for in the FPGA? > > Many thanks for any assistance on this matter. I see a couple of possibilities; 1. Use a microblaze in the fpga to control the spi bus and other control functions. (It may already use a microblaze, so update the code to do this internally, instead of taking commands from ethernet) 2. Use an E100 (or likely an E110) and write some code on the ARM to do the control tasks. Philip ---
**Author:** ![Reginald\_Cornwallic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/f14d63/32.png) [@Reginald\_Cornwallic](https://www.ruby-forum.com/u/Reginald_Cornwallic)\ **Post date:** [September 28, 2011, 12:25am UTC](https://www.ruby-forum.com/t/make-usrp-run-w-o-sw-intervention/212271/3 "2011-09-28T00:25:41Z")
On 09/27/2011 06:04 PM, Philip B. wrote: > I see a couple of possibilities; > > 1. Use a microblaze in the fpga to control the spi bus and other > control functions. (It may already use a microblaze, so update the > code to do this internally, instead of taking commands from ethernet) > There’s a ZPU in the FPGA–it handles some of the protocol and low-speed > interfacing “goop” in the normal firmware/FPGA load. > But the general “model” is that the FPGA/firmware is “dumb”. It > simply provides a fairly generic “peek and poke” interface over > the Ethernet, with all the “smarts” in the host code. I think part > of the motivation for this is that it’s easier to modify host code > for minor performance tweaks, etc, than doing it in the firmware/FPGA > code. But one could certainly enhance the small amount > of firmware that runs on the ZPU to handle all the device register > initialization, etc. – Marcus L. Principal Investigator Shirleys Bay Radio Astronomy Consortium > **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org/)** > > Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami. ---
**Author:** ![Reginald\_Cornwallic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/f14d63/32.png) [@Reginald\_Cornwallic](https://www.ruby-forum.com/u/Reginald_Cornwallic)\ **Post date:** [October 7, 2011, 4:34am UTC](https://www.ruby-forum.com/t/make-usrp-run-w-o-sw-intervention/212271/4 "2011-10-07T04:34:25Z")
Reginald, As already pointed out by Philip and Marcus, it is quite possible to modify the embedded firmware to initialize/hardcode SPI and internal FPGA register values. I’ve not looked at the firmware for the TCP/IP wrapper on packets that was added when UHD was introduced, but presumably you could hardcode an IP address there with similar difficulty. It’s hard to say if you would find this “simple” not knowing your software coding skills, but if you are capable of writing new FPGA verilog, then reverse engineering the firmware source should not be too challenging for you as it is relatively small and you have the FPGA source and H/W schematics to refer to which will help in your understanding. However this is not the approach I would recommend. I would suggest that whilst reading the firmware source will help you understand how the USRP is controlled by the host, it would be better to reverse engineer how the regular Source and Sink blocks work on the host, then write your own custom Host based application that programs FPGA and SPI registers and also packs unpacks the ethernet data stream to/from the USRP (which will be in your own proprietary framing format once drivers have removed/added UHD/IP/TCP headers). As you have observed it is relatively trivial to replace or enhance the DSP datapath on the FPGA and interface with the logic that packetizes the network traffic. If however your project is to make the N210 a fully self contained SMS Tx/Rx device then I caution you the project is very big, running even 2G GSM protocols on an embedded processor in the FPGA with the limited debugging and RAM resources will be very challenging. I’m assuming you have done some research on OpenBTS which may give you some good architectural ideas and perhaps a great starting point. -Ian