Author Topic: R&S RTB2004 Snooping  (Read 20205 times)

0 Members and 1 Guest are viewing this topic.

Offline ElectronManTopic starter

  • Regular Contributor
  • *
  • Posts: 111
  • Country: us
R&S RTB2004 Snooping
« on: September 20, 2020, 07:23:19 pm »
The other day I was looking at my RTB2004 and wondering what makes it tick. Given the availability of fully-optioned scopes with the COM4 bundle when it was launched, it seems to not hold a lot of interest for people to scrutinize its innards.

So, I took it apart and dug in to tease out its secrets. It is important to note that I am not focused on "hacking" licenses or anything like that. My interest is mostly in learning how it ticks.

With that out of the way, there are 3 prominent debug connectors on the bottom of the mainboard. There is a 4-pin white connector, a 10-pin white connector, and a special 12-pin red connector.

The 4-pin seems to have a 115.2kbps UART on it. It spits out unintelligible binary data immediately on boot.
The 12-pin red connector (helpfully labeled) appears to be JTAG for 2 Altera Cyclone V FPGA device instances according to openOCD.
The 10-pin white connector is the one I focused my efforts on. It is labeled HPS. This is for the Cyclone V's HPS (Dual core Arm Cortex A9 processor) that is built into their Cyclone V FPGA's, and is the primary processor that handles the UI.


Using this minimal OpenOCD config, I can get access to read/write memory, set breakpoints and watchpoints etc:

Code: [Select]
source [find interface/jlink.cfg]
reset_config trst_and_srst
if { [info exists CHIPNAME] } {
   set _CHIPNAME $CHIPNAME
} else {
   set _CHIPNAME fpgasoc
}
if { [info exists DAP_TAPID] } {
        set _DAP_TAPID $DAP_TAPID
} else {
        set _DAP_TAPID 0x4ba00477
}

jtag newtap $_CHIPNAME dap -irlen 4 -ircapture 0x01 -irmask 0x0f -expected-id $_DAP_TAPID
adapter_khz 4000

set _TARGETNAME1 $_CHIPNAME.cpu.0
target create $_TARGETNAME1 cortex_a -chain-position $_CHIPNAME.dap -endian little -coreid 0 -dbgbase 0x80110000
init
cortex_a dbginit

I started by examining memory dumps using OpenOCD's "dump_image" command. The memory configuration seems to put main SDRAM at memory address 0x10000000, and the CycloneV HPS memory mapping shows on-chip RAM @ 0xFFFF0000. The internal Altera Bootrom is @ 0xFFFD0000.

Access to memory is all well and good, but the contents of NAND flash would be even better. Inte'ls docs on the CycloneV HPS (https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410068585834.html) give detailed information on the I/O memory mapping of the NAND controller (0xFFB80000 for control, FFB90000 for data), and with openOCD it is possible to read/write these registers directly (we don't have a driver).

The NAND Flash is visible on the PCB, but just to verify functionality of the NAND controller while the CPU is halted, we can check appropriate registers with OpenOCD:


Doing some binary math, we can build and write a command to disable DMA on the NAND controller (necessary for our commands), select the first block and page, and read the first 16 words to verify we are getting good data.


With the particular command we are sending to the controller, it opens a page-size (2048 bytes) window @ 0xFFB90010 starting at the selected block/page. To get the full page we can just use openOCD's dump_image again, then select the next block/page and so forth. There are 4096 blocks with 64 pages per block with 2048 bytes per page.

A little scripting and 24hrs later (JTAG is SLOW) and you have a 512M NAND image.

binwalk returns a TON of images and files, some of the most interesting being the ELF binary executables, and the uBoot image:


The uboot image (via strings) has some interesting references to "MesOS" and appears to be an emergency boot image with debug capabilities:
Code: [Select]
[string]                       Writes a string.
<adr> <n>                      Loads n-bytes (binary) at <adr> in memory.
<src_adr> <n> <dst_adr>        Copys n-bytes memory from <src_adr> to <dst_adr>.
[<form> [<adr1> [<adr2>]]]     Displays memory at <adr1> to <adr2> with <form> (1, 2, 4 Byte).
<adr1> <adr2> [<pattern>]      Testing memory from <adr1> to <adr2> with <pattern> and !<pattern> (def: 0x55555555).
<adr> <value> <size>           Change memory at <adr> at <size> (1, 2, 4 Byte) to <value>.
<src_adr> <n> <dst_adr>        Copys n-bytes memory from RAM to NAND-Flash (<dst_adr> blockaligned!)
<src_adr> <n> <dst_adr>        Copys n-bytes memory from NAND-Flash to RAM (<src_adr> blockaligned!)
<dst_adr> <n> <value>          Fills n-bytes in NAND-Flash with <value> (<dst_adr> blockaligned!)
<log_adr> [<dst_adr>] [<n>]    Load and exec programm from <log_ adr> SD-Card/Nand at dst_adr ) with n-Byte (def: 0x73f33000 0x00120000 0x20000).
<adr>                          Start decrypted Update loaded at <adr>.
[<adr>]                        Quits 'MonDeb' and starts execution at <adr> (def: restart).
[<src_adr> [<n>]]              Update Monitor from RAM with <src_adr> (def.: 0x0c000000) and <n> Bytes (def.: 0x10000) AND REBOOT!!!
                               Quits 'MonDeb' and reboot at 0x0.
                               Quits 'MonDeb' and reboot at 0x0 too.
                               Displays the version of 'MonDeb'.
                               Displays the detailed version of 'MonDeb'.
                               Displays this short help.
                               Displays this short help too.
MonDeb>Quitting
Version:
Monitor & Debugger for MesOS
Hardware: CycloneVSoC
Version:
Date:     Oct  6 2016 16:40:22

The first ELF binary is ~2.2MB appears to be a firmware updater:
Code: [Select]
FWUPDATE
SERVICE
NVRAM
PWFUSB
OCFUSB
FUSB
TEST
DIAGNOSTIC
Please attach a USB flash drive containing a firmware update.
Abort!
Update failed!
Checksum incorrect!
Loading file info ... done.
No file found!
Loading file ...
The checksum of the firmware update is correct.
done.
Running update ... ! DO NOT SWITCH OFF THE DEVICE !
Reset internal memories ...
Update file OK.
Searching, please wait ...
USB flash drive ready.
File search starts in %i seconds.

The second one is ~20MB and appears to be the main binary. These are all static, stripped binaries with no relocations. The RTB2004 runs binaries bare-metal without an actual Operating system. This explains why it boots so quickly. You can see references to various memory areas via readelf, including .fpga_ram, which jives with the CycloneV HPS docs (0xc0000000 is the shared FPGA-HPS memory region).


I'm actually pretty impressed with what R&S has done here. Other vendors build on top of a pre-made OS. They seem to have developed their application for bare-metal and implemented it pretty efficiently. So far the most interesting stuff I have found reference a "textInit" file or folder on USB storage, but I haven't yet figured out if I can use this for something:
« Last Edit: September 21, 2020, 02:36:44 pm by ElectronMan »
 

Online tv84

  • Super Contributor
  • ***
  • Posts: 3217
  • Country: pt
Re: R&S RTB2004 Snooping
« Reply #1 on: September 20, 2020, 07:37:28 pm »
Finally!  :clap:
 

Offline ElectronManTopic starter

  • Regular Contributor
  • *
  • Posts: 111
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #2 on: September 20, 2020, 09:22:10 pm »
In case anyone wants to dump their own NAND, I have attached my messy perl script.

Pre-requisites:

- Perl installed with Net::Telnet CPAN package.
- OpenOCD must be configured and connected to the device via JTAG successfully.
- OpenOCD must be listening on a user telnet port
- The top of the script has settings that must be configured.

The script will halt the CPU of the scope, disable NAND controller DMA, and start dumping. It will take many hours. You can continue a dump by specifying the 2 parameters (./rtb_nand_dump.pl <starting_block> <starting_page>) and it will append to the configured file. Launching without those starts at block 0, page 0.

The script strips out the 16 byte block header that is on blocks 1 - 4095. This appears to be part of the NAND management and corrupts files if it is not removed before processing.

[Edit to attachment: Fixed bug with restarting from a specified page/block offset]
« Last Edit: September 21, 2020, 02:30:44 pm by ElectronMan »
 
The following users thanked this post: egonotto, jemangedeslolos, Belgarath, YetAnotherTechie

Offline Hydron

  • Frequent Contributor
  • **
  • Posts: 985
  • Country: gb
Re: R&S RTB2004 Snooping
« Reply #3 on: September 20, 2020, 11:11:44 pm »
ooh, very interesting, thanks!

I have one of the launch promo units, so as mentioned there isn't such a burning reason other than curiosity to poke around, though I did have a look at the SPI bus in mine to see if the front-end VGA was doing the bandwidth limit (probably not was the answer - didn't see any change when enabling the 20MHz limit).

Did you see the R&S Open Source Acknowledgement? Sounds like FreeRTOS might be in use:
https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_osa/RTB_OpenSourceAcknowledgment_en_01.pdf
 

Offline ElectronManTopic starter

  • Regular Contributor
  • *
  • Posts: 111
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #4 on: September 20, 2020, 11:22:11 pm »
ooh, very interesting, thanks!

I have one of the launch promo units, so as mentioned there isn't such a burning reason other than curiosity to poke around, though I did have a look at the SPI bus in mine to see if the front-end VGA was doing the bandwidth limit (probably not was the answer - didn't see any change when enabling the 20MHz limit).

Did you see the R&S Open Source Acknowledgement? Sounds like FreeRTOS might be in use:
https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_osa/RTB_OpenSourceAcknowledgment_en_01.pdf

Interesting. I haven't really seen anything pointing to that, though it could be modified and renamed. As far as I can tell the main ELF is called directly from the boot loader.

I have seen a number of libraries being referenced, such as "DietCrypto" used for option keys, and there are plenty of references to this custom library and others:
"E:/jenkins/OK-Legacy-Distribution-10/workspace/ok_services_oklib/Src/COptionKeyServiceLib.cpp"

I've noticed the main binary also accesses 3 different GPIO ports, and 2 i2c slave devices are present on the i2c bus. I haven't identified them as yet.
 
The following users thanked this post: YetAnotherTechie

Offline ElectronManTopic starter

  • Regular Contributor
  • *
  • Posts: 111
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #5 on: September 21, 2020, 05:06:13 pm »
I'm actually pretty impressed with what R&S has done here. Other vendors build on top of a pre-made OS. They seem to have developed their application for bare-metal and implemented it pretty efficiently.

As far as I know, R&S has programmed its own operating system 'MesOS', a similar one already existed in the Hameg instruments.

From the RTB2000 with undocumented SCPI command:
Code: [Select]
Build 522 built on 2018-11-06 12:37:30 by MaG? [02.202 - HCL: 03.300 - MesOS: 04.300] with GCC 5.3.0; Monitor: 03.711_CB2Ax00

Peter


Looks like that is probably the case then. Following the boot routines, I see it go to the Altera Bootrom first, then jumps to the little 44KB uBoot image at the beginning of Flash (with MesOS references) then jumps into the main ELF executable.
 

Offline ElectronManTopic starter

  • Regular Contributor
  • *
  • Posts: 111
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #6 on: September 27, 2020, 12:03:06 am »
It seems I did not look closely enough at the 4-pin connector. It is a typical 1.8V UART.

From the top of the photo I posted the first pin is GND, and the third pin is UART TX (Device out TX 115.2kbps, 8N1, idle=low).

I haven't yet been able to get a response when attempting to transmit on pins 2 or 4, so cannot identify the RX yet.

This is the output immediately following poweron:

Code: [Select]
U-Boot SPL 2013.01.01 (Oct 06 2016 - 16:39:22)
BOARD : Altera SOCFPGA Cyclone V Board
CLOCK: EOSC1 clock 50000 KHz
CLOCK: EOSC2 clock 50000 KHz
CLOCK: F2S_SDR_REF clock 0 KHz
CLOCK: F2S_PER_REF clock 0 KHz
CLOCK: MPU clock 925 MHz
CLOCK: DDR clock 400 MHz
CLOCK: UART clock 100000 KHz
CLOCK: MMC clock 62500 KHz
CLOCK: QSPI clock 3613 KHz
RESET: WARM
SDRAM: Initializing MMR registers
SDRAM: Calibrating PHY
SEQ.C: Preparing to start memory calibration
SEQ.C: CALIBRATION PASSED
SDRAM: 512 MiB
NAND:  Denali NAND controller

The very first thing this U-boot image does is to check GPIO2, PIN 7 to see if it is low, and enters the "MonDeb" debug monitor if it is. So far I can't find a front-panel button that maps to that port/pin, so I am not sure what is supposed to trigger that. It could be that some device asserts that when it has a problem, or some front-panel combination I am missing so far.
« Last Edit: September 27, 2020, 02:23:15 am by ElectronMan »
 
The following users thanked this post: YetAnotherTechie

Offline darkstar49

  • Frequent Contributor
  • **
  • Posts: 309
Re: R&S RTB2004 Snooping
« Reply #7 on: September 28, 2020, 03:55:12 pm »
 :clap:

didn't see this before...  well done !!! I'm rather a software guy, I had a (quick) look at the FW files (RTB, RTM, RTA), but these are all encrypted, so there was not much to chew without an image of the  boot rom and/or the FW update code (to which I had no access...).
 

Online tv84

  • Super Contributor
  • ***
  • Posts: 3217
  • Country: pt
Re: R&S RTB2004 Snooping
« Reply #8 on: September 29, 2020, 08:48:49 am »
This is the output immediately following poweron:

No "Hit any key to stop autoboot: " ?
 

Offline ElectronManTopic starter

  • Regular Contributor
  • *
  • Posts: 111
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #9 on: September 29, 2020, 05:53:36 pm »
This is the output immediately following poweron:

No "Hit any key to stop autoboot: " ?

Nope. I only see 2 code checks that cause the "Mondeb" diagnostics to load.

It checks a GPIO pin, and branches into it with no error if it is low. Otherwise it checks a memory location and branches into it with an error about being unable to start the bootloader.

I managed to force it to take the first code path by changing a register value. So far I have not been able to get a response from UART to keypresses, and I believe it is an issue with my UART dongle.

I got a new one and will be retesting soon.
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 824
  • Country: es
Re: R&S RTB2004 Snooping
« Reply #10 on: September 30, 2020, 06:32:05 am »
Maybe that gpio is on one of those debug connectors? Would be more logical than having it accessible on the front panel (if the mode it triggers requires access to internal UART). Try grounding unknown pins (using some 500 Ohm resistor to stay safe) while observing that gpio reg bit via JTAG?
 
The following users thanked this post: ElectronMan

Offline ElectronManTopic starter

  • Regular Contributor
  • *
  • Posts: 111
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #11 on: October 01, 2020, 12:42:37 am »
Maybe that gpio is on one of those debug connectors? Would be more logical than having it accessible on the front panel (if the mode it triggers requires access to internal UART). Try grounding unknown pins (using some 500 Ohm resistor to stay safe) while observing that gpio reg bit via JTAG?

Could be. I was a bit wary of connecting together things that were unknown, so I went the software route to get past it.

I've finally made some progress on producing some IDA and Ghidra FunctionID signatures for these binaries too (figuring out the compiler options they used was a bear).
 

Offline reyntjensm

  • Regular Contributor
  • *
  • Posts: 119
  • Country: be
Re: R&S RTB2004 Snooping
« Reply #12 on: October 05, 2020, 11:21:54 pm »
I don't understand what you are trying to achieve? Just to see how R&S has build there software? I also have an RTB2004 and i'm very happy with it. I got a big discount on the scope with a lot of options( just send them an email and you can buy straight from the manufacturer, if you ask for a discount they can do some things). Sadly enough i don't have the full bandwith option. I only have 70 MHz.... If you know how to hack it to 300MHz please let me know :D. Do you know if the FFT functions depend on the bandwith option? I'm not sure about this since i can use the FFT above the 70MHz bandwith. It looks like you are doing very difficult stuff. I hope you don't blow up the logic with poking around, but i'm sure you know what you are doing with this ;)
 

Offline ElectronManTopic starter

  • Regular Contributor
  • *
  • Posts: 111
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #13 on: October 06, 2020, 03:07:03 am »
I don't understand what you are trying to achieve? Just to see how R&S has build there software? I also have an RTB2004 and i'm very happy with it. I got a big discount on the scope with a lot of options( just send them an email and you can buy straight from the manufacturer, if you ask for a discount they can do some things). Sadly enough i don't have the full bandwith option. I only have 70 MHz.... If you know how to hack it to 300MHz please let me know :D. Do you know if the FFT functions depend on the bandwith option? I'm not sure about this since i can use the FFT above the 70MHz bandwith. It looks like you are doing very difficult stuff. I hope you don't blow up the logic with poking around, but i'm sure you know what you are doing with this ;)

I just like to know what is inside the "black boxes" that I own. If I find something "useful" or provide a path for someone else to find something useful, all the better.

I am pretty much done poking around the insides. I made a JTAG cable and ran it out the little door in the back so I can connect back up if I need to test something. I am using the firmware I recovered to learn more about software reverse-engineering in general. I have no plans to do anything potentially destructive, as this is my primary scope right now.
 
The following users thanked this post: Harjit

Online tv84

  • Super Contributor
  • ***
  • Posts: 3217
  • Country: pt
Re: R&S RTB2004 Snooping
« Reply #14 on: October 07, 2020, 08:35:36 pm »
Preloader: U-Boot SPL 2013.01.01 (Oct 06 2016 - 16:39:22)
Loading address - 0xFFFF0000

Bootloader:
Code: [Select]
00010000                 Magic: 27051956    uImage File OK
00010004         Header CRC-32: FB7A652B  [00010000-0001003F]    CRC OK
00010008               Created: 06/10/2016 14:40:27
0001000C             Data Size: 0000AFB0
00010010     Data Load Address: 00100000
00010014   Entry Point Address: 00000000
00010018           Data CRC-32: 8CF4BA9E  [00010040-0001AFEF]    CRC OK
0001001C      Operating System: U-Boot Firmware
0001001D      CPU Architecture: ARM
0001001E                  Type: Firmware Image
0001001F           Compression: None
00010020                  Name: Monitor CycloneVSoC CB-2Ax
00010040 - Image 0 [00010040-0001AFEF]  0000AFB0 bytes

I included also a NAND visual map of its contents (512MB). The initial zone is the bootloader + 7 .ELF files.

Code: [Select]
Offset     Size    CRC32     ???        #
00020001  00222DA0 667AD7B6 0177B8C9  00000000  [00020040-00242DDF]  CRC OK
0025FEE1  011C2270 99B593B8 017889C3  00000001  [0025FF20-0142218F]  CRC OK
0143F5F1  01249710 0F20C41A 017A8953  00000002  [0143F630-02688D3F]  CRC OK
0269ECC1  01255230 13A3E181 017C7C27  00000003  [0269ED00-038F3F2F]  CRC OK
038FE391  01364C10 55559A0E 0180559F  00000004  [038FE3D0-04C62FDF]  CRC OK
04C7D9D1  013C9110 35F2A042 0185479D  00000005  [04C7DA10-06046B1F]  CRC OK
0605CFE1  01482CF0 DE645734 0188065F  00000006  [0605D020-074DFD0F]  CRC OK
« Last Edit: October 08, 2020, 01:11:52 pm by tv84 »
 
The following users thanked this post: YetAnotherTechie

Offline YetAnotherTechie

  • Regular Contributor
  • *
  • Posts: 221
  • Country: pt
Re: R&S RTB2004 Snooping
« Reply #15 on: October 07, 2020, 11:47:01 pm »
Thank you ElectronMan for your investigation!
Can you please post your version numbers?
About the NAND, i suggest not stripping but saving the extra NAND bytes to a separate file, this could help in the future to repair a corrupted dump/chip.
Do you know that those chips have unique data sectors, that can be programmed only once, have you considered reading them too?
 

Offline ElectronManTopic starter

  • Regular Contributor
  • *
  • Posts: 111
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #16 on: October 09, 2020, 12:24:23 am »
Thank you ElectronMan for your investigation!
Can you please post your version numbers?
About the NAND, i suggest not stripping but saving the extra NAND bytes to a separate file, this could help in the future to repair a corrupted dump/chip.
Do you know that those chips have unique data sectors, that can be programmed only once, have you considered reading them too?

I haven't looked at any of the spare areas on the NAND chip. Everything appears to be out in the open. I can take an image easily enough with the NAND formatting in it, though I don't trust JTAG for writing back to my NAND unless I've got no other choice.

Here are the versions (I have never installed most of these, so they must come on there from the factory):
Code: [Select]
25FF20: " [01.100 - HCL: 02.500 - MesOS: 03.760] with GCC 5.3.0"
143F630: "Build 39 built on 2017-03-02 15:39:23 by SBC [01.203 - HCL: 02.500 - MesOS: 03.760] with GCC 5.3.0"
269ED00: " [01.210 - HCL: 02.500 - MesOS: 03.760] with GCC 5.3.0"
38FE3D0: " [02.000 - HCL: 03.100 - MesOS: 04.100] with GCC 5.3.0"
4C7DA10: " [02.121 - HCL: 03.200 - MesOS: 04.200] with GCC 5.3.0"
605D020: " [02.202 - HCL: 03.300 - MesOS: 04.300] with GCC 5.3.0"
« Last Edit: October 09, 2020, 12:53:18 am by ElectronMan »
 

Offline ElectronManTopic starter

  • Regular Contributor
  • *
  • Posts: 111
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #17 on: October 09, 2020, 12:31:24 am »
Found something interesting in memory. 32 bytes, padded with zeros on the end.... I wonder if they use the default AES256-CBC initialization vector for encrypting their firmware......  ::)

« Last Edit: October 09, 2020, 12:42:11 am by ElectronMan »
 
The following users thanked this post: uski

Online tv84

  • Super Contributor
  • ***
  • Posts: 3217
  • Country: pt
Re: R&S RTB2004 Snooping
« Reply #18 on: October 09, 2020, 10:03:46 am »
 :clap: :clap: :clap:

IV=0
« Last Edit: October 09, 2020, 12:04:45 pm by tv84 »
 
The following users thanked this post: uski

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 824
  • Country: es
Re: R&S RTB2004 Snooping
« Reply #19 on: October 09, 2020, 12:20:46 pm »
Great! I was afraid they hid it in the FPGA part  >:D
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13726
  • Country: gb
    • Mike's Electric Stuff
Re: R&S RTB2004 Snooping
« Reply #20 on: October 09, 2020, 02:10:27 pm »
Maybe that gpio is on one of those debug connectors? Would be more logical than having it accessible on the front panel (if the mode it triggers requires access to internal UART). Try grounding unknown pins (using some 500 Ohm resistor to stay safe) while observing that gpio reg bit via JTAG?
A connector pin or test pad would be my guess as well.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: ElectronMan, ppeterl

Offline ElectronManTopic starter

  • Regular Contributor
  • *
  • Posts: 111
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #21 on: October 09, 2020, 03:49:02 pm »
Maybe that gpio is on one of those debug connectors? Would be more logical than having it accessible on the front panel (if the mode it triggers requires access to internal UART). Try grounding unknown pins (using some 500 Ohm resistor to stay safe) while observing that gpio reg bit via JTAG?
A connector pin or test pad would be my guess as well.

It is the second pin down on the UART 4-pin connector from my photo above. I grounded that through a 500Ohm as abyrvalg suggested and I see the GPIO pin register change to low for the pin were were interested in.

Edit:
I tested this. It looks like you need to un-ground it for the debug prompt to come up. So it seems it is supposed to be like holding a button during power-on then releasing it.

Unfortunately, even with my new serial dongle, I am not getting any response from the device when trying to type commands. The bottom connector must be RX, as it is the only one left.  Still investigating that.
« Last Edit: October 09, 2020, 04:01:21 pm by ElectronMan »
 

Offline KaneTW

  • Frequent Contributor
  • **
  • Posts: 805
  • Country: de
Re: R&S RTB2004 Snooping
« Reply #22 on: October 09, 2020, 04:01:18 pm »
Very cool!
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 824
  • Country: es
Re: R&S RTB2004 Snooping
« Reply #23 on: October 09, 2020, 07:59:38 pm »
Great! If you know UART IO addresses you can try finding Rx the same way as that gpio - setup the PC to send something to the dongle port continuously, touch Rx candidate pins with your dongle’s Tx while observing the UART status/data regs via JTAG.
 

Offline ElectronManTopic starter

  • Regular Contributor
  • *
  • Posts: 111
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #24 on: October 09, 2020, 09:19:40 pm »
Great! If you know UART IO addresses you can try finding Rx the same way as that gpio - setup the PC to send something to the dongle port continuously, touch Rx candidate pins with your dongle’s Tx while observing the UART status/data regs via JTAG.

I finally figured it out... The Mondeb interface actually uses that same GPIO pin to receive. It provides no echo (so you have to turn on local echo).

You have to send BREAK (usually Alt-B on terminals) at the end of each command. You also need to hold BREAK while turning it on to trigger the debug terminal.

So from the top of the photo in the original post, the pins on the 4-pin debug connector are:
1 - GND
2 - UART RX
3 - UART TX
4 - VCC?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf