Hi Nick, Please send me also the n210.bit file. I experience the similar problem as was presented in: [Discuss-gnuradio] Getting USRP N210 running http://lists.gnu.org/archive/html/discuss-gnuradio/2010-12/msg00222.html
The safe mode by pressing J2 doesn't work. So I want to try re-program the FPGA. BTW: How can I generate the .bit file myself using the FPGA source code. I'm a Layman to FPGA. :) Bests, Hanwen 2011/4/20 Nick Foster <n...@ettus.com> > On Wed, 2011-04-20 at 10:13 +1000, Vladimir Negnevitsky wrote: > > Hi folks, > > > > We've recently received an N210. I updated the firmware successfully a > > few times, but then usrp_n2xx_net_burner.py crashed. I immediately > > tried rewriting the image, and all seemed to go fine, however both > > default and backup booting (holding S2 during powerup) failed. I > > directly programmed the FPGA over JTAG using iMPACT and a Xilinx > > platform cable, and the firmware loaded correctly. At this point I ran > > usrp_n2xx_net_burner.py twice with both the default and the > > --overwrite-safe options. Rebooting into both the default and safe > > images worked fine and FLASH burns have worked since then. > > This is something that's strangely come up three times this week on the > list, under similar circumstances, despite several months of (mostly) > trouble-free updates. We've been so far unable to replicate it here or > deduce why it's happening, and I've got an N210 here which I've been > continuously updating for several hours without incident. Either it's > cosmic rays, or something else we haven't found yet. Can you please send > me the following information: > > * OS and version > * UHD host code version > * FPGA/firmware versions > * Ethernet card model > * Any hub or switch in between the PC and the N210? > * What exactly was the behavior of the net burner app? Did it crash, or > stall? What arguments did you invoke it with? > > > > > I have a feeling I was very lucky. Since I only reprogrammed the FPGA, > > it would have searched the FLASH for working ZPU firmware, which must > > have been intact. My question is, is there any technique to recover > > the N210 in the event that both the FPGA and ZPU firmware are corrupt? > > I've seen it alluded to in old posts where the CPU and FPGA firmware > > were accidentally written into each other's locations. The technique > > would be very useful if a similar crash happens again and it *does* > > overwrite the CPU firmware this time. I'd also like to hear others' > > success (or failure) stories. > > You're right about the mechanism of recovery. In the future, if the > updater crashes, locks up, or otherwise behaves anomalously, do the > following before rebooting: > > Re-load the safe firmware and FPGA image with the --overwrite-safe > option of the N210 firmware updater (NEVER USE THIS OPTION OTHERWISE). > Use the latest N210 images from the UHD download site for this step. It > should then be safe to reboot. > > For future reference, if you (or anyone else) manage to brick your N210 > using the firmware updater, we'll be happy to issue an RMA to have it > recovered here. If you'd like to recover it yourself, it's really not > that hard, provided you have a Xilinx Platform JTAG cable and a USB to > RS232 (3.3V logic level ONLY) adapter. Here's how to bootstrap it: > > 1. JTAG program FPGA with n210.bit (email me for it, it's just the .bin > file with a header, but iMPACT requires it). The FPGA bootloader will > start and won't find software, so it falls back to an Intel HEX prompt. > If your firmware hasn't been erased, it will boot the firmware, the LEDs > on the front panel will go through their startup sequence, and you can > skip step 2. > > 2. Build the N210 firmware from the latest UHD master (or I can email it > to you). Connect the USB-RS232 adapter (be SURE it's 3.3V logic level > output!) to J305 -- the silkscreen labels the pinout. Run the program > firmware/zpu/bin/uart_ihex_ram_loader.py <path-to-.IHX-file>. The IHX > file will be named usrp2p_txrx_uhd.ihx. The RAM loader should say "USRP2 > + found" and start loading. When it finishes, it will load the program. > > 3. At this point the device is up and running like a regular USRP N210, > and you should be able to write firmware and FPGA images to it. Use the > --overwrite-safe option of the N210 firmware update program to write > safe FPGA and firmware images first, then load production FPGA and > firmware images. Use the latest N210 images from the UHD download site. > After loading all four images, go ahead and reset the device. It should > now be operating normally. > > > We apologize for any inconvenience, and we'll find an explanation for > the issue as soon as possible. > > --n > > > > > > Best regards, and thanks for your help. > > > > Vlad > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
