GD-77 internal RAM memory snapshots

posted in: Development, DMR, Ham radio | 8

Now that I have a hardware debugger connected to my GD-77, and the processor is not read protected, I’ve been able to take some snapshots of the 128k internal RAM memory in the GD-77 by while the firmware was paused.

To make the files easy for anyone to read, I’ve exported the raw data, using the Hxd hex editor program, using its Editor View

 

These first 2 files, are where its in channel mode, and I’m changing from a channel on talk group 505 to a channel with the same frequency, but on talkgroup 3801

 

gd77_Channel_shs_5050_2_TG505_43912500_RAM

gd77_Channel_shs_5050_2_TG3801_43912500_RAM

 

The next to were both on the same channel,  but with and without monitor mode

 

gd-77_RAM_tg505_monitor

gd-77_RAM_tg505_normal

 

I had hoped to be able to spot which memory location holds the monitor mode flag, but the problem is that just turning on or off monitor mode, changes the display (briefly) and plays a beep sound, so that a lot of the memory is changed, not just the variable that contains the monitor mode setting. Hence I’ve not been able to find the monitor mode variable using this method.

 

Last, I took some snapshots of the RAM with the GD-77 in VFO mode, where I changed the frequency between each snapshot.

The frequency in the first snapshot was 439.125MHz and in the second one its 439.1375 Mhz

I think it should be possible to find where the current frequency is being stored, but I’ve not had chance to investigate this as yet.

gd77_VFO_TG99_43912500_RAM

gd77_VFO_TG99_43913750_RAM

 

 

Having a general look at the memory snapshots, there are some things to note.

 

  1. I prefilled the RAM with 0xDEADBEEF, so any areas that still contain this pattern, do not seem to be used by the official firmware, and hence can hopefully be used for enhancements
  2. A lot of RAM is filled with the word “kats” (over and over again). I don’t know why kats is used, but its 4 bytes long, which is a good size to use for a 32 bit processor as most variables and pointers will be 32 bits (4 bytes long).
    I suspect perhaps “kats” is the Chinese equivalent of DEAFBEEF but I’m not sure.
    I think that this pattern is used to somehow reserve memory, but again, I’m not sure how or why.
  3. The RAM seems to contain what appears to be a history of some channels which I selected in the radio a few days ago. These are analog channels and not part of the Zone which I had selected for all the tests.
    I will need to look in the external flash, and also the EEPROM, because the RAM is volatile and would not have retained this information.
  4. There appears to be other things in memory which I didn’t expect to me there, like what appears to be bitmap patterns for the display characters

 

Anyway, I though I may as well post this, in case anyone else can spot anything useful in the RAM

 

Update.

Following a very useful comment from @rootstar

 

I have recreated a binary dump using firmware 3.1.8, just after the radio has booted up. No buttons have been pressed etc

I’ve uploaded a zip of this RAM dump and also included my codeplug. The channel selected is in the DHS zone and is called DHS 505:2

TG is 505 on TS2, Tx freq is 431.800Mhz and Rx freq is 438.800Mhz

gd-77_3_1_8_TG505_RAM

 

I’m going to try using Ghidra to decompile version 3.1.8 and see if I can also import this RAM snapshot

 

 

8 Responses

  1. r00tstar
    |

    What is the address range of the ram? And can you post binary dumps? I can combine the ram + rom in ida and it will show which functions are accessing what. This is 3.1.1 or 3.1.8?

  2. Roger Clark
    |

    The dumps are for firmware 3.2.1

    I can recreate them for an older firmware.

    RAM in the ML22 MCU is from 0x1fff0000 to 0x2000ffff, ( 128k )

    It’s a good idea to import it, but I don’t know if it’s possible to import multiple files into the same Ghidra project, like it is on IDA

    Currently I was looking at firmware 3.2.1, but I think I may go back to a previous version which does not have the frequency limits.

    Which version do you prefer ?

    Edit.

    I’ve updated the post to include a dump just after the radio booted up while running firmware 3.1.8

    I think you’re right. There is no point in using firmware 3.2.1 as its only purpose is to impose frequency limits.

  3. r00tstar
    |

    Oh snap… I was loading it int 3.1.1 since that’s what was released and things weren’t matching up. I can do whichever version, I think 3.1.8 is the best idea since they fixed nothing and imposed frequency limits in 3.2.1; as you said. I had actually edited the text file with macros and ripped the dump out but now I’ll try it correctly. Might be good to combine flash + ram + rom and disassemble the whole thing. I just wish there were more strings in there to go off of.

  4. Roger Clark
    |

    The zip file I just uploaded was dumped when running 3.1.8

    Was that the one you tried ?

    BTW. I can’t seem to get Ghidra to import 2 files into the same project space.

    I can create multiple memory segments, only blank ones, I can’t import to create a new memory segment in the same project space 🙁

    I’ve raised an issue for this on Github, and hopefully someone will know how to do it or have a workaround

    PS. I also tried to make a merge multi segment motorola .mot data file that I could read into Ghidra, which contained the 2 memory blocks, but that didnt seem to work either

    PPS.

    I think I realise why I saw remnants of other zones in one of my other snapshots.
    The firmware is probably using either a pool of memory or using malloc and then not just loading the zone names, but also probably all the info about the Zone, when it I press the Zone button.

    I think the developers didnt need to worry too much about RAM, as they seem to keep a lot of things loaded, which on smaller MCU’s you’d have needed to just cherry pick what you wanted to load.

  5. r00tstar
    |

    Yes, I see menus in ram too, plus there is chinese text as some of the strings are doubled. Has to be a hidden language selection and test/rf test. Only some tasks and USB functions really have names so lots of work ahead, at least you can live debug. I tried to find the range for the external flash chip but so far no luck, the ram is called all over fw and matches now so combining all 3 would be cool. Then getting a list of the basic functions like malloc, free, etc. The good news is that there looks to be lots of room to expand in fw, ram and flash.

  6. Roger Clark
    |

    Thanks…

    I can use GDB, but at the moment I’m manually having to set breakpoints by typing in the addresses.

    The stack trace feature in GDB doesn’t seem to be working very well, it only shows the last 3 items on the stack, because GDB finds “duplicate frames” (duplicate addresses) on the stack and then gives and error”

    The external Flash is accessed via SPI, and I can find some places in the code which are something to do with accessing the flash, because there is a reference to the address range of the DMR ID section (0x30000 – 0x50000), but that’s all I’ve found.

    I tried looking for numbers relating to the calibration data in the flash, but there are too many references in the code to that address, because its 0x8f000 (see http://members.optuszoo.com.au/jason.reilly1/GD-77tune.htm ), and this seems a common bit pattern.

    I don’t think Ghidra has a interface to GDB, but I may post a feature request for this, as often Ghidra has the feature I want, but its hard to find it.

  7. ken
    |

    thanks

  8. Roger Clark
    |

    I’ve done some more experiments today and did a RAM snapshot when I was transmitting, and I think I’ve found the location in RAM of the Rx Group List and also several places that contain the Tx TalkGroup

    For anyone whose interested, In firmware 3.1.8,

    I’ve found what appears to be the Tx data structure with the Tx TG located at 0x3a04, which is the lower 3 bytes of this 32 bit value and the Rx Group list appears to be held at memory address 0x3a08 (plus base address of memory of 0x1fff000) hence 0x1fff3a08 (i.e just after this)

    I don’t know yet, what the upper byte of the Tx TG signifies. It seems to be 0x05 if I’m on a channel, and 0x90 if I’m on the VFO. It may be a bit pattern.

    This finding, should allow me to eventually add the feature to enable TG entry via the keypad, but at the moment I don’t know where the keypad functions are located in the firmware.

Leave a Reply