GDB + Register View

[LostTime77]

Hi

I have been trying to find some information on a register view for an embedded micro in particular an ARM . However, it does not seem like visual GDB provides any type of register view mechanism. The only thing that I think it provides is a memory view, where you can view and write the contents of any memory address. I know that GDB allows you to print the CPU registers out and view and write memory. For this, visual GDB also has a GDB command window that you can communicate with.

What would be involved in adding a register view for an ARM micro that includes CPU registers and memory mapped peripheral registers? A visual studio plugin is possible, but we would like whatever solution that is devised to integrate with the entire visual GDB debugging experience. For example, in eclipse, the user clicks the debug button, and they can easily have access to a register view for say an EFM32GG990 micro in a window.

My first thought would be to get the stream for the interactive GDB console and start sending down commands to it and receiving commands. Since we don’t want to read out all the register contents every time, the UI should only read and write registers that the user clicks on , etc..

[ket]

Hi,

You can view CPU registers in the Registers window (can be shown from Debug->Windows->Registers during debugging) in Visual Studio. Then right-click on the Registers window and select which register groups to show.
For some embedded devices we show a special peripheral registers window, otherwise enter the peripheral register name into the Watch window to see its value.

[LostTime77]

Writing the name of the register in the watch window is not at all desirable. That is simply one step above writing the direct address of the register in a memory view; it is a sprinkle of sugar. We want the entire package of sugar, not a sprinkle. Every time we have to debug the registers, we don’t want to have to remember the name of the register and type it in. A peripheral register view is desirable and a basic component of embedded bare metal debugging (which we must do). IAR Eclipse provides this functionality.

I am not asking the Visual GDB team to implement this feature, I am simply asking how we could proceed in writing our own simple viewer.

[support]

Hi,

Thanks for letting us know this feature is important for you. We already support peripheral register listing for msp430, but we did not add it for ARM yet.
You can easily let VIsualGDB display the registers of your MCU by editing some of the configuration files manually:
1. Ensure that your .vgdbsettings file has a reference to an embedded profile file (e.g. stm32.xml):

Debug







MinGWUnixSlash



$(ProjectDir)

stm32.xml



...

2. In the embedded profile file add an MCUDefinitionFile element pointing to an XML file on your disk:

com.visualgdb.arm-eabi

com.sysprogs.arm.stm32

STM32F407VG

...

e:stm32registers.xml

3. Create an MCU definition file listing the peripheral registers in the following format:

stm32-demo





GPIOC





MODER

32

0x40020800






IDR

32

0x40020810

Once you create those, start debugging and open the Hardware Registers window to see the contents of your registers.

[LostTime77]

This is an interesting feature. I am assuming this is undocumented?

I don’t want to nag, and this feature would almost be complete. If I was going to implement such a feature, I would do it in a similar way. HOWEVER!

I am not clear if this xml file supports nesting for the hardware register definitions. Don’t get me wrong. I hate Eclipse with a passion, but it is what we develop with. The debugger is so – so. Eclipse IAR does though have a nice register view layout (while it may be buggy). For each MCU, the register modules are grouped. You can drill down into those groups and get at the data. For example, for a GPIO module, the group would be GPIOA. You then click on this group and you drill down to ODR, IDR, etc.. Another one might be the RCC module. At the lowest level, the view even gives you the register bits for that particular register.

So, is it possible to nest the register definitions into multiple nodes / groups? What about bit fields? If I have a 32 bit peripheral register, bit 0 might represent enabling clock A. Bit 20 might represent that a timer timed out. Eclipse IAR has these type of bit field views at the lowest level.

Again, let me emphasize that if you cannot do this and or do not plan on supporting such functionality in the register view, we have no problem whatsoever making our own register view that has such functionality. This was my intention in the first place.

[support]

The current design supports two levels of nesting:
1. You can define register sets that support registers. This is implemented and fully supported.
2. You can define bit ranges inside each register. Each bit range can be mapped to a combo box with predefined values or a check box. This is supported by the VisualGDB back-end but we don’t have GUI for it yet.

Here’s the definition of the hardware register-related types in VisualGDB:

    public class HardwareSubRegister
{
public string Name;
public int FirstBit;
public int SizeInBits;

/// 


/// Only valid when contains array of (1 << SizeinBits) strings.

/// If set, instead of showing one of the actual integral values, a corresponding string

/// should be displayed and a combobox should be used.

/// 


public string[] KnownValues;



[XmlIgnore]

public HardwareRegister ParentRegister;

}



public class HardwareRegister

{

public string Name;

public int SizeInBits;

public string Address;          //0x...

public string GDBExpression;    //Optional, can be derived from Address

public bool ReadOnly;

public HardwareSubRegister[] SubRegisters;

}



public class HardwareRegisterSet

{

public string UserFriendlyName; //If not set, not displayed either

public HardwareRegister[] Registers;

}

Do you think this format supports all the grouping you need? If no, please give us an example of grouping that is not supported. If yes, please give us a sample XML file with the grouping you want so that we could add this feature to our GUI.

[LostTime77]

From what I can see, you are almost there with the feature set we would “like”. Now, I am not saying you have to go further than you have. We can probably work within what you have implemented. However, a nice feature would be arbitrary levels of nesting, or several more levels of nesting.

From what I see, you support 2 levels of nesting: GPIOC -> MODER -> bit1, or RCC -> AHBPENR -> USBCLKEN (bit 1) for example. If we take a queue from eclipse, eclipse supports at least 3 levels of nesting. For example: GPIO -> GPIOA, GPIOB, GPIOC, etc.. -> MODER -> bit1. Furthermore, you do not seem to have a UI yet for your second level of nesting. We would like to request that the 2nd level of nesting ‘at least’ be implemented in the UI.

I am not quite sure I understand how you are planning on displaying the 2nd level of nesting. It seems complicated to put that inside a combo box for the bit fields. If you want, I can provide a screenshot of how Eclipse does the nesting and displays all the register data in the view. In my opinion, Eclipse has a very nice register view where you can easily view the registers at each level of the nesting.

[LostTime77]

I apologize: I just looked in eclipse, and it looks like Eclipse supports 2 levels of nesting and not 3 from what I can see. If you implement the 2nd level of nesting in the UI, I think that would be OK for us.

Here is a screenshot I just took of the Eclipse register view and layout I am comparing to. At the top level you have the “register set”. At the 2nd level you have the hardware register, and at the third level you have the bit fields. The view is very fluid, because all you have to do to go to a nested level is click the little tree expand arrow.

[ket]

Hi,

Please try the newly released VisualGDB version 4.1r10 (http://visualgdb.com/download/).

It includes extended GUI support for the Hardware Registers window, all three levels are now shown, the subregister values can be viewed and edited.

[darksilence]

@ket wrote:

Hi,

Please try the newly released VisualGDB version 4.1r10 (http://visualgdb.com/download/).

It includes extended GUI support for the Hardware Registers window, all three levels are now shown, the subregister values can be viewed and edited.

Where??? I can’t find this window! Where should I look?

[ket]

Hi,

The Hardware Registers window opens automatically during debugging when supported by the board support package. Currently MSP430 and STM32 devices have support for the Hardware Registers window. If you are debugging a supported device but cannot see the window, then you can show it manually at Debug->Windows->Hardware Registers.

[darksilence]

I found a problem.
so! BSP_ROOT is c:Usersuser1AppDataLocalVisualGDBEmbeddedBSPsarm-eabicom.sysprogs.arm.stm32

if we open a file stm32.xml (in a project dir), we can see:

C:Usersuser2AppDataLocalVisualGDBEmbeddedBSPsarm-eabicom.sysprogs.arm.stm32devicesstm32f407xx.xml

So of course i don’t have this file because i’m not , i’m . And because we work with SVN we can’t provide the same path.

How can i change a stm32.xml file? I tryed to copy stm32f407xx.xml and stm32f407xx.xml.gz to the project dir. but it doesn’t work.

Please help us solve it =/

Also,we would be much happyer if you’ll make special menu for VisualGSB with all setting and features… (like Visual Assist or QT menu)

[support]

Hi,

The latest release of VisualGDB stores relative paths in the MCU XML file. Simply change the path to devicesstm32f407xx.xml if you have created your project using an older version.
You can browse all VisualGDB-related settings via Tools->Options->VisualGDB.

[magicstocki]

Hi,
it seems that I have the same problem, I’m using VisualGDB 4.3 for an embedded project with an STM32. I converted the project to a stand alone project an the register view doesn’t appear anylonger when I’m debugging. The Debug->Windows->Hardware Registers doesn’t appear too. I checked the configuration files “.vgdbsettings”, “stm32.xml” and stm32ff407.xml”, they all located in the same directory.

“.vgdbsettings”

<?xml version="1.0"?>
<VisualGDBProjectSettings2 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <ConfigurationName>Debug</ConfigurationName>
  <Project xsi:type="com.visualgdb.project.embedded">
    <CustomSourceDirectories>
      <Directories />
      <PathStyle>MinGWUnixSlash</PathStyle>
    </CustomSourceDirectories>
    <MainSourceDirectory>$(ProjectDir)</MainSourceDirectory>
    <EmbeddedProfileFile>stm32.xml</EmbeddedProfileFile>

“stm32.xml”

<?xml version="1.0"?>
<EmbeddedProfile xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<ToolchainID>com.visualgdb.arm-eabi</ToolchainID>
<BspID>com.visualgdb.bsp.in-place</BspID>
<McuID>STM32F407VE</McuID>
<BSPSubdirectory>BSP</BSPSubdirectory>
<MCUProperties>
<Entries />
</MCUProperties>
<BSPSourceFolderName>Device-specific files</BSPSourceFolderName>
...
<MCUDefinitionFile>stm32f407xx.xml</MCUDefinitionFile>
</InPlaceMCU>
<MCUMakFile>stm32.mak</MCUMakFile>
</EmbeddedProfile>

In an other project which is not converted to a stand alone project it works fine.

• This reply was modified 9 years, 2 months ago by magicstocki.
• This reply was modified 9 years, 2 months ago by magicstocki.
• This reply was modified 9 years, 2 months ago by magicstocki.

[support]

This is a known bug in 4.3 that has been fixed in 5.0.

[Author]

Posts