discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Bricking and recovery of N210


From: hanwen
Subject: Re: [Discuss-gnuradio] Bricking and recovery of N210
Date: Sat, 27 Aug 2011 15:41:11 +0200

Hi Nick,
 
Please send me also the n210.bit file.
I experience the similar problem as was presented in:
[Discuss-g​nuradio] 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 <address@hidden>
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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


reply via email to

[Prev in Thread] Current Thread [Next in Thread]