usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsDevice Serial, Name and Product ID Corruption Issue on Misusage of b2xx_fx3_utils for B210
Hello,
I have an Ettus B210 device that I have been experimenting with for some time. I had a need to turn on and off the device on a remote host. I intended to apply the bootloader for fx3 to the device. While playing around with the b2xx_fx3_utils, I loaded the bootloader of the device with “usrp_b210_fpga.rpt” by mistake. After following the steps by Benito Horta discussed in the B200 shows up as Cypress FX3 USB Bootloader Device FIXED steps taken, I managed to recover from this situation somewhat.
Problem:
- Device cannot be initialized though api calls (such as from Python) or uhd_usrp_probe etc.
Error Message:
- "Error: RuntimeError: B200 unknown product code: 0x3120"
Cause:
- My suspicion is that the device mb eeprom: serial, name and product ID are corrupted (from what I understand from the error message and the uhd_find_devices output).
Note that the uhd_find_devices output is,
[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; DPDK_21.11; UHD_4.3.0.0-release
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
serial: SP48A1s:
name: 6 25%
product: B2??
type: b200
I am using UHD-4.3 and Ubuntu 22.04. I tried loading firmware, FGPA and bootloader files using ./b2xx_fx3_utils.
I read About the Motherboard and Daughtercard EEPROM on USRP Devices and I need guidance on using the ./usrp_burn_mb_eeprom tool. Has anyone had anything like happened before? I worry the eeprom writes are undoable, nevertheless, any suggestion about the issue is appreciated.
Cheers,
Eden.
On 08/08/2023 03:56, edenmclaughlin123@gmail.com wrote:
Hello,
I have an Ettus B210 device that I have been experimenting with for
some time. I had a need to turn on and off the device on a remote
host. I intended to apply the bootloader for fx3 to the device. While
playing around with the b2xx_fx3_utils, I loaded the bootloader of the
device with “usrp_b210_fpga.rpt” by mistake. After following the steps
by Benito Horta discussed in the B200 shows up as Cypress FX3 USB
Bootloader Device FIXED steps taken
https://usrp-users.ettus.narkive.com/7S6MYwCo/b200-shows-up-as-cypress-fx3-usb-bootloader-device-fixed-steps-taken,
I managed to recover from this situation somewhat.
Problem:
Device cannot be initialized though api calls (such as from
Python) or uhd_usrp_probe etc.
Error Message:
"Error: RuntimeError: B200 unknown product code: 0x3120"
Cause:
My suspicion is that the device mb eeprom: serial, name and
product ID are corrupted (from what I understand from the error
message and the uhd_find_devices output).
Note that the uhd_find_devices output is,
[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; DPDK_21.11;
UHD_4.3.0.0-release
-- UHD Device 0
Device Address:
serial: SP48A1s:
name: 6 25%
product: B2??
type: b200
I am using UHD-4.3 and Ubuntu 22.04. I tried loading firmware, FGPA
and bootloader files using ./b2xx_fx3_utils.
I read About the Motherboard and Daughtercard EEPROM on USRP Devices
https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices
and I need guidance on using the ./usrp_burn_mb_eeprom tool. Has
anyone had anything like happened before? I worry the eeprom writes
are undoable, nevertheless, any suggestion about the issue is appreciated.
Cheers,
Eden.
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
What happens if you use "--read-all" on usrp_burn_mb_eeprom?
That will give you a list of what it thinks the various keys in EEPROM are.
Dear Marcus,
When I type that, it prints the same run-time error:
./usrp_burn_mb_eeprom —read-all
Creating USRP device from address:
[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; DPDK_21.11; UHD_4.3.0.0-release
Error: RuntimeError: B200 unknown product code: 0x3120
What’s interesting is the device firmware can be loaded with power cycle but the same error persists throughout the UHD utilities and usrp related code.
I think the desired output should be similar to the following as provided on About the Motherboard and Daughtercard EEPROM on USRP Devices under B200/210 and B200mini EEPROM:
Fetching current settings from EEPROM...
EEPROM ["revision"] is "4"
EEPROM ["product"] is "2"
EEPROM ["serial"] is "30AD2D4"
EEPROM ["name"] is "MyB210"
Regards,
Eden.
On 08/08/2023 09:36, edenmclaughlin123@gmail.com wrote:
Dear Marcus,
When I type that, it prints the same run-time error:
|./usrp_burn_mb_eeprom —read-all|
*Creating USRP device from address: *
[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; DPDK_21.11;
UHD_4.3.0.0-release
Error: RuntimeError: B200 unknown product code: 0x3120
What’s interesting is the device firmware can be loaded with power
cycle but the same error persists throughout the UHD utilities and
usrp related code.
I think the desired output should be similar to the following as
provided on About the Motherboard and Daughtercard EEPROM on USRP
Devices
https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices
under B200/210 and B200mini EEPROM:
Fetching current settings from EEPROM... EEPROM ["revision"] is "4"
EEPROM ["product"] is "2" EEPROM ["serial"] is "30AD2D4" EEPROM
["name"] is "MyB210"
Regards,
Eden.
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
I think the basic problem is that when you had it load up that FPGA
image as the FX3 bootloader image, the EEPROM values were
over-written--the FX3 "load me a new bootloader" code has no idea
what the internal semantics are.
The .img file that Ettus ships in ...uhd/images doesn't include values
for the EEPROM (which makes sense, because they're
set at the factory).
I'm trying to find out if there's a bootloader image that includes
"sane" values for the EEPROM that can be loaded using
fx3_utils.
Dear Marcus,
I very much appreciate your help, that makes sense, it was probably the cause…
In regards to the bootloader image that includes EEPROM values that you pointed out, I am going to look into the files.ettus.com/ to see if I can find any suitable image.
Regards,
Eden.
On 08/08/2023 10:57, edenmclaughlin123@gmail.com wrote:
Dear Marcus,
I very much appreciate your help, that makes sense, it was probably
the cause…
In regards to the bootloader image that includes EEPROM values that
you pointed out, I am going to look into the files.ettus.com/
https://files.ettus.com/ to see if I can find any suitable image.
Regards,
Eden.
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
Loking at he code for b200_fx3_utils, it doesn't appear possible for it
to do what happened to you--it won't let you load an
image that is large enough to clobber the upper 256 bytes of EEPROM,
which is where the critical EEPROM variables are
stored.
It MIGHT be the case that it loaded that bogus bootloader, started
executing it, and through some miracle, that code actually
overwrote the top 256 bytes of the 32KB EEPROM that is on the B200.
Hi again Marcus,
I see, so, I am guessing I better contact the Ettus and ask them to send me a new image or the device need a whole EEPROM replacement? What action would you recommend me to take?
Sorry if I am sounding foolish, but this exceeds my experience about SDR’s. Thank you in advance and so far for the answers!
Best Regards,
Eden.
On 08/08/2023 15:00, edenmclaughlin123@gmail.com wrote:
Hi again Marcus,
I see, so, I am guessing I better contact the Ettus and ask them to
send me a new image or the device need a whole EEPROM replacement?
What action would you recommend me to take?
Sorry if I am sounding foolish, but this exceeds my experience about
SDR’s. Thank you in advance and so far for the answers!
Best Regards,
Eden.
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
If you send a note to support@ettus.com, they may be able to issue an
RMA and do a factory-reset type thing.
It would be possible to create an image that includes the EEPROM area
with "sensible" values, but that would also require
running a modified version of UHD that doesn't have any "safeguards".
Awesome! I will get in touch with them ASAP and comment here later for the records. Thank you for everything!
Best wishes,
Eden.
On 08/08/2023 15:10, edenmclaughlin123@gmail.com wrote:
Awesome! I will get in touch with them ASAP and comment here later for
the records. Thank you for everything!
Best wishes,
Eden.
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Also, I wonder about the ".rpt" file you reported--that is generated by
FPGA build tools, and is not something that is shipped
in the usual image files. We DO ship .rpt files for some of the
other products, but not by default for B2xx.
Oh, it is located under the install_prefix/share/uhd/images/. for me.
I have a UHD-4.3 installation and it is built from the source. It goes by the name usrp_b210_fpga.rpt and it came bundled with uhd_images_downloader. I don’t recall installing any image from an outside source.
Regards,
Eden.
On 08/08/2023 15:28, edenmclaughlin123@gmail.com wrote:
Oh, it is located under the install_prefix/share/uhd/images/. for me.
I have a UHD-4.3 installation and it is built from the source. It goes
by the name usrp_b210_fpga.rpt and it came bundled with
uhd_images_downloader. I don’t recall installing any image from an
outside source.
Regards,
Eden.
Interesting. I don't see any .rpt files in the (somewhat newer) UHD
source tree that I have. Are you also building the FPGA
images from source? That would explain why you have the
corresponding .rpt file. Regardless, those files are text, and
are a "resource report" from the FPGA tools.
If you could share an "ls -l" on that file, that can help me understand
what might have happened....
Most definitely, but I am currently away of my workstation therefore I cannot share that file right now.
I will copy its contents to this thread tomorrow, it will be posted here in 12 hours at the most. Will that be an issue?
Please, excuse me for this one!
Regards,
Eden.
On 08/08/2023 15:55, edenmclaughlin123@gmail.com wrote:
Most definitely, but I am currently away of my workstation therefore I
cannot share that file right now.
I will copy its contents to this thread tomorrow, it will be posted
here in 12 hours at the most. Will that be an issue?
Please, excuse me for this one!
Regards,
Eden.
No worries. I'll check back tomorrow.
I am currently only using the default FPGA images for my B210 that are, I think, downloaded with the uhd_images_downloaded, is installed to the device with the b2xx_fx3_utils tool.
It is installed to the same directory as above, install_path/uhd/share/images/.
Regards,
Eden.
Hi Marcus,
Good Morning! I hope you are doing well. I have ls -l ‘d the install_prefix/share/uhd/images/usrp_b210_fpga.rpt file that you asked for. Here is the output for that file:
- -rw-r--r-- 1 root root 1518 May 26 15:57 usrp_b210_fpga.rpt
It is a total of 1.5K which is far less than 32KB meaning the b2xx_fx3_tools could have been able to load the contents of the report as you coined @Tue, Aug 8, 2023 2:34 PM. I also typed down the contents below so the viewers can have a look.
---======
Device utilization summary:
---------------------------
Selected Device : 6slx150fgg484-3
Slice Logic Utilization:
Number of Slice Registers: 34280 out of 184304 18%
Number of Slice LUTs: 37206 out of 92152 40%
Number used as Logic: 31106 out of 92152 33%
Number used as Memory: 6100 out of 21680 28%
Number used as RAM: 1560
Number used as SRL: 4540
Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 50601
Number with an unused Flip Flop: 16321 out of 50601 32%
Number with an unused LUT: 13395 out of 50601 26%
Number of fully used LUT-FF pairs: 20885 out of 50601 41%
Number of unique control sets: 805
IO Utilization:
Number of IOs: 180
Number of bonded IOBs: 163 out of 338 48%
IOB Flip Flops/Latches: 156
Specific Feature Utilization:
Number of Block RAM/FIFO: 190 out of 268 70%
Number using Block RAM only: 190
Number of BUFG/BUFGCTRLs: 4 out of 16 25%
Number of DSP48A1s: 152 out of 180 84%
---======
Timing Summary:\n
All constraints were met.
---======
I hope the report is readable at all.
By the way, you have mentioned about a modified version of UHD. I am guessing it is not but is it publicly available by any chance or is it disclosed to the end-users under some conditions maybe? Would it be possible for me to configure an EEPROM image myself for any version of the UHD given I know the device’s serial no. part no. etc.?
If there is any alternative way to sending the device for a repair, I would be happy to try it out. Looking forward for your response!
Best wishes,
Eden.
On 09/08/2023 03:46, edenmclaughlin123@gmail.com wrote:
Hi Marcus,
Good Morning! I hope you are doing well. I have |ls -l| ‘d the
|install_prefix/share/uhd/images/usrp_b210_fpga.rpt| file that you
asked for. Here is the output for that file:
-rw-r--r-- 1 root root 1518 May 26 15:57 usrp_b210_fpga.rpt
It is a total of 1.5K which is far less than 32KB meaning the
b2xx_fx3_tools could have been able to load the contents of the report
as you coined @Tue, Aug 8, 2023 2:34 PM. I also typed down the
contents below so the viewers can have a look.
---======
Device utilization summary:
---------------------------
Selected Device : 6slx150fgg484-3
Slice Logic Utilization:
Number of Slice Registers: 34280 out of 184304 18%
Number of Slice LUTs: 37206 out of 92152 40%
Number used as Logic: 31106 out of 92152 33%
Number used as Memory: 6100 out of 21680 28%
Number used as RAM: 1560
Number used as SRL: 4540
Slice Logic Distribution:
Number of LUT Flip Flop pairs used: 50601
Number with an unused Flip Flop: 16321 out of 50601 32%
Number with an unused LUT: 13395 out of 50601 26%
Number of fully used LUT-FF pairs: 20885 out of 50601 41%
Number of unique control sets: 805
IO Utilization:
Number of IOs: 180
Number of bonded IOBs: 163 out of 338 48%
IOB Flip Flops/Latches: 156
Specific Feature Utilization:
Number of Block RAM/FIFO: 190 out of 268 70%
Number using Block RAM only: 190
Number of BUFG/BUFGCTRLs: 4 out of 16 25%
Number of DSP48A1s: 152 out of 180 84%
---======
Timing Summary:\n
All constraints were met.
---======
I hope the report is readable at all.
By the way, you have mentioned about a modified version of UHD. I am
guessing it is not but is it publicly available by any chance or is it
disclosed to the end-users under some conditions maybe? Would it be
possible for me to configure an EEPROM image myself for any version of
the UHD given I know the device’s serial no. part no. etc.?
If there is any alternative way to sending the device for a repair, I
would be happy to try it out. Looking forward for your response!
I'm just guessing that manufacturing has a tool that does what you
need. I have some queries into the appropriate groups in
Ettus/NI.
I did a fair amount of investigating yesterday, and the .img file is NOT
just a linear blob of bytes, but has internal structure,
including address fields, etc. So even though the file was only
1.5kb, it could still corrupt any address in the EEPROM, and
even some FX3 configuration registers.
The EEPROM locations for the things in question here start at 32512 (256
bytes less than the 32KB size of the EEPROM).
The map for it is in:
.../uhd/host/lib/b200/b200_mb_eeprom.cpp
const std::unordered_map<std::string, eeprom_field_t> B200_REV1_MAP = {
{"magic", {0, 2}},
{"eeprom_revision", {2, 2}},
{"eeprom_compat", {4, 2}},
{"vendor_id", {6, 2}},
{"product_id", {8, 2}},
{"revision", {10, 2}},
{"product", {12, 2}},
{"name", {14, NAME_MAX_LEN}},
{"serial", {14 + NAME_MAX_LEN, SERIAL_LEN}},
// pad of 210 bytes
};
Best wishes,
Eden.
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
Hi Marcus,
Well, that makes it clear how such a small file could corrupt pretty much to the end of the EEPROM. I will keep those in mind. I am currently checking the b2xx_fx3_utils.cpp file. I will let the readers know if I find anything noteworthy about the discussion.
Thank you, have a wonderful rest of your day,
Eden.
Hi Marcus,
I hope your are doing great! I was wondering if you got a response from the respective groups in Ettus/NI that you mentioned? What have they got to say?
Cheers,
Eden.
On 11/08/2023 02:50, edenmclaughlin123@gmail.com wrote:
Hi Marcus,
I hope your are doing great! I was wondering if you got a response
from the respective groups in Ettus/NI that you mentioned? What have
they got to say?
Cheers,
Eden.
Ettus R&D are now aware of the issue, but I don't expect a quick
response. You may be best, at this point to request an RMA
through support@ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com