In “How to Add Register Details View in Eclipse” I showed how to add the Register detail support in Eclipse using the EmbSysRegView plugin. This was for Luna/Mars, and for the version v0.2.4 of the plugins.
Since then, there is a new version of Eclipse (MARS, see “Going to Mars: Building a DIY Eclipse IDE for ARM Embedded Microcontrollers“) and the EmbSysRegView plugin has been updated to v2.0.5. Makes everything much simple, so here is an updated post with the details how to add register detail view to Eclipse Mars.
Use the menu Help > Install new software and use the following update site to install the viewer and data files:
This installs a set of Freescale SVD files inside this folder (at least on my Windows 7 machine):
Freescale includes newer and added SVD files in their KDS v3.0.0 or Processor Expert for KDS v3.0.x releases. If you have installed Processor Expert plugin (see “Going to Mars: Building a DIY Eclipse IDE for ARM Embedded Microcontrollers“), then you have the files
So what I did is the following:
- Renamed the ‘Freescale’ folder in the v0.2.4 plugin to ‘Freescale.0.2.4’
- Copied the Freescale from the 0.2.4 plugin
That way I keep the original files and have the new files added. And I can switch between them in the EmbSysRegView settings:
If you don’t have Processor Expert, then you find a collection of SVD files on SourceForge.
EmbSysRegView already comes with a set of Freescale SVD files. To get the latest and newest devices, the above article explains how to install them into a DIY Eclipse installation.
Happy Registering 🙂
PS: The GNU ARM Eclipse plugins come with a nice register viewer too. I plan to feature that register detail viewer in a next post, so stay tuned 🙂
- EmbSysReg Viewer Project: http://embsysregview.sourceforge.net/
- Using EmbSysReg: https://mcuoneclipse.com/2014/05/29/how-to-add-register-details-view-in-eclipse/
- Kinetis Design Studio V3.0.0: http://www.freescale.com/kds
- Additional SVD Freescale Files: SourceForge
It is worth mentioning where these plug-in files can be found. I am sure it is different for Linux, but on my machine they were at:
Note the “.” in front of p2.
I used the path on my Windows 7 machine, and for sure it is something different on Linux.
nice news!Thank you very much!!!
Hi Erich – small typo:
> the EmbSysRegView plugin has been updated to v2.0.5.
Should read v0.2.5.
Nice post as usual.
Just one question about this plugin: is it possible to watch Cortex Mx core registers too?
I mean R0…R12, PC, SP, LR, PRIMASK and so on.
Thanks a lot
No, for this you need to use the normal ‘Register’ view, as all these registers are not memory mapped. The EmbSysRegView works on memory mapped registers only.
Thanks a lot!
Pingback: Going to Mars: Building a DIY Eclipse IDE for ARM Embedded Microcontrollers | MCU on Eclipse
The plugin is not working on GNU ARM eclipse. It shows the registers but none is being updated, I double click on PCR22 for example and it turns green but there isn’t any number showing in HEX nor Bin. Do you have any idea of what could be happening?
you only can read register values if you are debugging and connected to the target.
I’m debugging and connected to the target, I have no idea why it is not working. Is this affected by the debugger I’m using? Because I have flashed the debug mcu with the open segger j-link.
I’m using Segger J-Linkn too, and do not have problems. Have you selected the correct CPU in the EmbSysRegVîew?
Yes I have selected the correct CPU. I got frustrated and installed KDS to see if it works fine and the EmbSysRegView is working correctly.
It’s just that I have my eclipse marte setup to work in projects for STM32, PIC32 and Kinetis and I’d like to get it to work with this eclipse since I would like to avoid have multiple IDEs installed, specially if I can work with just one with the right plugins installed.
Also the “Peripherals” view causes “arm-none-eabi-gdb.exe” to crash in the eclipse marte, therefore I can’t see the peripheral registers anywhere.
So it might be indeed a gdb problem. KDS is using an older GNU ARM Embedded (launchpad) version. I have seen several crashes in the latest gdb too, so this might be related.
Just added this, but also can’t read the actual values. Nothing in the hex or bin columns. Is this because it doesn’t work with P&E Open SDA interface, possibly?
I have not seen any issues, I can use it with OpenOCD, P&E and Segger including OpenSDA. The plugin does not depend at all on the debug probe, as long as it is able to read/write memory through GDB.
Strange. It shows the values of the general registers(r0, sp etc), but none of the EmbSys Registers…
I take it the general registers are specified elsewhere, e.g. in the Cortex M0+ definitions?
The general CPU registers (r0, etc) are not memory mapped, and are accessed differently.
So something seems to go wrong with the EmbSysRegView accessing memory. You might check the console view (GDB and GDB traces).
This gives a log what is happening with GDB. You can turn on GDB traces with Help > Preferences > C/C++ > Debug > GDB > Enable GDB traces.
Maybe this shows why the memory access is not working?
Check as well if your Memory view is able to access the peripheral register space.
Just me being stupid. I didn’t realize one had to double-click. In my defence, I will say that there is no double-click required for General Registers….
Yes, you have to double click. This might be confusing at the beginning, but it makes sense only to read the values from the registers which are needed. Because reading registers could cause some side effects.
Another dumb question. When debugging under KDS, using the PE Open SDA, does the target run at full speed(obviously not when paused or single stepping)? My USB HID port to the FRDM-KL26Z seems to work 100 times better if I connect ONLY the target USB cable, and not the Open SDA one.
I have not noticed something like this. But make sure you don’t have any watchpoints or other things active on the debugger side which would do periodic checks of the target. Maybe you have a view open which does start/stop your target. Try closing as many open views in Eclipse to find out which one could be the one affecting your target. The other thing is: you could enable GDB traces (Window > Preferences > C/C++ > Debug > GDB) and then check the console view if something is accessing your target in the background.
Should have said – using KDS
Pingback: First Steps with Ozone and the Segger J-Link Trace Pro | MCU on Eclipse
Pingback: Tutorial: Getting ETM Instruction Trace with NXP Kinetis ARM Cortex-M4F | MCU on Eclipse
Pingback: MCUXPresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers | MCU on Eclipse