New Carrier Bring-up "0000000000000102: E> NONE: Invalid value MemBct dram size: 0MB for slot: 2."

Hi,

I’m trying to bring-up a new Jetson Xavier NX carrier. We have a carrier that we’ve been using for a couple of years, this new carrier is just the same but in a different form factor.

There are some small differences between the design of the old and new carrier which I could explain if anyone thinks it is relevant.

Because we believe that this new carrier is the same as the old carrier I’ve tried to flash the NX using the same procedure. I have an old and new carrier on my desk. I can flash the NX on the old carrier. I then connect the USB to the new carrier but when I repeat the commands, ./flash.sh fails.

The error message that I see is:

[  10.8854 ] Sending bct_mem
[  10.9354 ] [................................................] 100%
[  10.9413 ] 0000000000000102: E> NONE: Invalid value MemBct dram size: 0MB for slot: 2.
[  10.9578 ]

Is there anything I can try to debug what’s going on?

At the moment I don’t know if this could be a problem with the new carrier or if I need to do something different in the flashing procedure.

The Jetson Xavier NX modules have the same part number, 900-83668-0030-000. I haven’t tried moving a module between carriers because it is quite hard to disassemble the old carrier and remove the heat sinks.

Below is a longer extract of the output I see, I can provide more if anyone thinks it will help.

Any thoughts greatly appreciated,
Matt

./flash.sh -d /mnt/zeus/081_CHARM100NX/Software/216_3uvpxDeviceTree/tegra194-p3668-all-p3509-0000_3uvpx.dtb -r jetson-xavier-nx-devkit-emmc mmcblk0p1
###############################################################################
# L4T BSP Information:
# R32 , REVISION: 5.1
###############################################################################
# Target Board Information:
# Name: jetson-xavier-nx-devkit-emmc, Board Family: t186ref, SoC: Tegra 194,
# OpMode: production, Boot Authentication: NS,
# Disk encryption: disabled ,
###############################################################################
copying soft_fuses(/home/v4/nvidia/nvidia_sdk/JetPack_4.5.1_Linux_JETSON_XAVIER_NX/Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-soft-fuses-l4t.cfg)... done.
./tegraflash.py --chip 0x19 --applet "/home/v4/nvidia/nvidia_sdk/JetPack_4.5.1_Linux_JETSON_XAVIER_NX/Linux_for_Tegra/bootloader/mb1_t194_prod.bin" --skipuid --soft_fuses tegra194-mb1-soft-fuses-l4t.cfg --bins "mb2_applet nvtboot_applet_t194.bin" --cmd "dump eeprom boardinfo cvm.bin;reboot recovery"
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands

...

[   8.6111 ] Boot Rom communication
[   8.6122 ] tegrarcm_v2 --chip 0x19 0 --rcm rcm_list_signed.xml
[   8.6131 ] BR_CID: 0x880219116430b007240000000efe0140
[   8.6404 ] RCM version 0X190001
[   8.6845 ] Boot Rom communication completed
[   9.7002 ]
[  10.7043 ] tegrarcm_v2 --isapplet
[  10.7067 ] Applet version 01.00.0000
[  10.7791 ]
[  10.7792 ] Sending BCTs
[  10.7820 ] tegrarcm_v2 --download bct_bootrom br_bct_BR.bct --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt --download bct_mem mem_rcm_sigheader.bct.encrypt
[  10.7844 ] Applet version 01.00.0000
[  10.8753 ] Sending bct_bootrom
[  10.8758 ] [................................................] 100%
[  10.8771 ] Sending bct_mb1
[  10.8812 ] [................................................] 100%
[  10.8854 ] Sending bct_mem
[  10.9354 ] [................................................] 100%
[  10.9413 ] 0000000000000102: E> NONE: Invalid value MemBct dram size: 0MB for slot: 2.
[  10.9578 ]
[  10.9578 ]
Error: Return value 2
Command tegrarcm_v2 --download bct_bootrom br_bct_BR.bct --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt --download bct_mem mem_rcm_sigheader.bct.encrypt
Failed flashing t186ref.

Are you talking about you flash the same module with same BSP version but just change the carrier board?

We’ve fitted a new Jetson Xavier NX module in the new carrier. When I get the error message it is for a module that has never been programmed before.

I could try fitting a previously programmed module to the new carrier. I just wanted to see if anyone had any ideas before I try that.

Try to put the old module on your new carrier board first.

If old module cannot reproduce issue, then it is due to new module has PCN update.

Ok, thanks. :-)

On Monday I’ll talk to the hardware team and see if we can extract a programmed module from the old carrier assembly.

Hi,

I’m really sorry this was our fault and not a problem at all! :-(

It turned out the modules weren’t the same. Various mix ups, miscommunications and misunderstandings conspired to ensure we had a module on the new carrier that was different to what we use on the existing carrier. It’s impossible to see the module part number when it is out assembly.

I’ve just successfully programmed the correct module on our new carrier. :-)

Thanks for your help,
Matt

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.