newcdb Linux Silicon Labs EC2 Silicon Labs EC3


  • Read / Write microprocessors Flash memory
  • Source level debugging
  • Aims to support all Silicon Labs CIP-51 core processors

Latest news


No I haven't gone away, Just been busy with other projects. I discovered a bug in the USB device detection that was always there but which only had an effect after the changes to support the new toolsticks were added. This bug caused my EC3 to not work sometimes. This should be fixed. I'm still looking into the toolstick issues and have one arriving shortly to do some more testing with.

-- Ricky


I have finally found time to look at a data capture provided by Frieder Ferleman for the newer toolsticks that did not work with ec2drv. It turns out the issue is simple, these ones don't have the bootloader that the older ones have. I have hacked up some code to skip the bootloader sequence for these toolsticks unfortunatly I do not have one of these devices so I cannot test it. This code is now in the subversion trunk. I have checked that it does not break the EC2/3 support.

I would appreciate any feedback good or bad for these newer toolstick devices. If it dosen't work running

ec2device --port=USB --debug
would provide some very useful data.



I have finally found time to look at a data capture provided by Frieder Ferleman for the newer toolsticks that currently don't work with ec2drv. It turns out the issue is simple the new ones don't have the bootloader that the older ones have.

I have hacked up come changes that shold work with these toolsticks or be very close to working but unfortunatly I do not have one of these devices to test with so I would appreciate any feedback. I have committed the code th the subversion trunk and checked that it does not break the EC2 / 3 debugger support.



I have added a --run command to ec2writeflash that leaves the processor in a running condition after ec2writeflash exits and after a suggestfrom from Hyunwoo Park. Device detection on the EC2 has been made more robust thank to Hyunwoo.

New code has been added to the debugcore to help support kdev51 by allowing kdev51 to use a background thread to detect when the processor has halted. newcdb may be updated to the new functions at some point but for now 2 variants of the halt functions exsist. kdev51 is comming along nicely. Loading, running and stepping through code works but the breakpoint managment isn't quite there yet. If you are getting bored with newcdb+ddd give it a try at

-- Ricky


I'm moving ec2drv over to using subversion. This will make it easier to work with both ec2drv and kdev51. There is now an SVN copy of ec2drv and after I've confirmed the import its ok I will remove the referance to CVS from the project page and documentation. Unfortunatly sourceforge does not provide a way to disable access to the old CVS repository. To cope with this once the SVN is confirmed good I will remove files from the CVS repo and replace them with a prominant readme pointing to the SVN repo.

-- Ricky


I've got a kdevelop plugin building that dosen't need to modify the kdevelop sources. Currently It dosen't do too much. I have created a new sourceforge project to keep its development separate. kdev51 - 8051 debugging plugin for kdevelop I expect to commit an initial version into SVN in the next few days. I currently supports reading / modifying registers from the GUI. Next on my list is getting breakpoints working and a project creation profile done that has the kdev51 set to be loaded.



I broke newcdb with the split but I think I have fixed it now. At least it should not segfault on changing targets now. Please let me know if there are still problems.



I have made a preliminary split between the newcdb gdb-like interface and the core source level debugging logic. This will allow building a debugging application that dosen't use the gdb interface but indtead interfaces directly. This split is not complete yet. Some functionality in the new debug-core directory will be moved out to the newcdb directory This will mainly be interface code that became too intertwined with the code. Hopefully I haven't broken newcdb. I gave it a quick check with an 8051F120 board and an EC2 and it ran fine. I think that the old default behaviour of starting the simulator as a default target is now gon so for the simulator you must type set target S51 followed by set target connect.

I have been expirimenting with kdevelop plugins and I think that the best way to implement debugging is to implement a debugging part for kdevelop that uses the new to interface to both simulators and debuggers.



Hi All, I've been busy with redecorating over for the last month or so and had been working on meeting software deadlines for work so I didn't feel like doing much software at home so ec2drv got a bit neglected. Hopefully now I can find a bit more time to solve some of the remaining issues.


Julian has provided more patches that fix adding breakpoints to asm files by line number and impove formatting of some newcdb output. Also a change to make sure when a new file is loaded with the file command in newcdb that the internal data structures in newcdb are reset.

I have made some progress on the print command support of newcdb. It works for arrays, string and other basic types but there is no support for structures yet. For arrays print the whole array works but printing part will only work for single dimention arrays so far. This is in CVS but expect a few rough edges.


Julian has found a few more undocumented registers that need to be used instead of the real SFR addresses. In particulat the DPTR registers. This explaines why "info registers" always showed the DPTR as some strange value. This is now fixed in CVS.


I have applied a set of patches received from Julian Lamb that fix multiple issues with newcdb. these changes are in cvs. Check ectdrv/ChangeLog for details.


After a few bug reports about USB issues I have looked into the initialisation sequence some more. There were a few obvious errors. I have fixed those and added error reporting for all USB operations so debugging of issues involving USB should be easier.


I've added a file called 60-silabs.rules to the CVS copy of ec2drv in the ec2drv/doc directory. If you copy this into /etc/udev/rules.d/ it allows EC3 access on Fedora Core 6 for any user that is part of the silabs group.

After placing the rules file in the correct place you must run

udevcontrol reload_rules 

To add a user to this group as root you can use the following but you should run the groups command to get a list of the groups you are currently a member of. The usermod -G option needs a comma seperated list of the groups to associate the user with. You must include all the groups you are currently a member of as seen by the groups command because the -G option will remove you from any groups not listed! see man usermod for more info.

		groups username
		usermod -Gsilabs,group1,group2... username

This is basically a modification to the rule in ubantu-usb.txt that Kolja provided to make it work with Fedora.



Thanks to Sean Collins providing useful data captures and testing ec2drv now supports the C8051F53x family :-). The C8051F52x family should also be easy to support now since they are very similar (same data sheet and same major device id to the F53x). The only missing link is the unique device id sequence. I'll have to try and setup my ec2 simulator again to recover this unless someone has a F52x they can report the results of ec2device for.


Thanks to Steve the debug test in the CVS version should now pass for the F320/1 processor as he confirmed the breakpoint registers are the same as for the F310. Also today I've finally fixed my F310 board and promptly discoved a bug affecting writing to xdata. I have now fixed this and committed it to CVS. -- Ricky


Thanks to Steve Brown a fix for miss identified processors on EC3 debuggers has been checked into CVS. This may also fix other issues relating to the use of the EC3 & Toolstick USB debuggers on some platforms.

I have also checked in some initial code to allow the print function in newcdb to work. This does work for the simple.c test program but the scoping issues and composite variables are not handled yet but support is not far away.
I am able to use print i and print j to see the variables increment for the simple.c test program. This works on the simulator and on real hardware. The support for specifing output format is also in progress and should be available shortly.



Although I've been busy the last few weeks I'm making great progress with the print functionality in newcdb and hopefully will have something to commit to CVS during the weekend. The extra type parsing from the CDB file is now handled so I have the symbol information necessary to do this.

I have also created a set of test functions which I have been using to confirm newcdb handles breakpoints correctly with s51, C2 micros & JTAG micros. the s51 support sometimes dosen't get the breakpoints quite right (seems to stop on nonexsistant ones sometimes) but the C2 mode on a F300 seems to work ok for the simple.c test program. The s51 support should be quite simple to fix when I get time to look into it. I think I might not be making sure the simulators breakpoints are always reset before loading new ones.




I have added a wiki to the website which I will use to document the protocol used by the EC2 / EC3 and other aspects of the project.
Please feel free to contribute pages on anything related the ec2drv.

Add F35x to the list of supported processors


With the help of Julian Lamb who provided excellent data captures and preformed the tests on his board, ec2drv now works with the F35x family on both EC2 and EC3 debuggers :-).
This was a little difficult to debug in that it used a slightly different xdata write read command set for the EC3 and a slight variation on the one used for the EC2.

Still making progress


I'm still making progress although I've been busy as usual, good feedback has been received that is helping to make sure more processors are supported and helping to clean up a few issues whoch should make for a better release

Here is a link to Rodolfo Giometti's project which is a Linux kernel driver for programming C2 devices over a parallel interface without a debugger. It doesn't appear to support the debug features.
Parallel port programming and debugging is something I have had in the back of my mine as a nice to have and would like ec2drv to support. I think ec2drv provides enough framework to figure out the exact C2 commands that the debugger sends out to the micro for each request. Since ec2drv separates the back ends out it should be easy to provide an appropriate back end while keeping to top end debugger/interface the same.

Maybe there is some way to use Rodolfo's code to provide the high speed C2 interface in kernel space but provide a generic interface to userspace to that ec2drv can craft C2 messages. This would be interesting but I have other things to get going before looking at anything like that. (If anyone is interested in doing it let me know) -- Ricky

Please test CVS head


The core driver and ec2tools seem to be working ok with my testing but it would be good for others to test and report success / failure before I make a proper release.
Meanwhile I'm cleaning up the cdb support a little. -- Ricky

Sourceforge Anonymous CVS working again


It looks like the sourceforge anonymous CVS is working at an acceptable speed again so no more need for the snapshot.

New firmware tools


There are now a tool to read firmware images directly from an EC3 / EC3 or Toolstick. The firmware image format being used has changed. see firmware for more information on how to use the new read tool and how to write the new format images into your debugger.

It seems the bootloader is quite robust in that writing applications of all zeros or even just garbage doesn't turn the debugger into a brick.

With these new tools it is possible to program the debugger to do something else since the .raw images are just 8051 binaries.

Thanks to Kolja Waschk firmware reads and writes can be checked because he figured out the checksum used in the debuggers bootloader.

Please note I have updated the website with the details of the new tools although the tools are only available in the CVS version at this moment and instructions will be incorrect for the old ec2drv 0.4 release. You should be using the CVS version, it is much improved!

split up of functions proving helpful.


The split up of the source into multiple files is already paying off as its much easier to make a change to jtag and know that you haven't broken C2 etc. the file sizes are much more manageable too.

Bulk of the JTAG / C2 split complete


I have performed the bulk of the splitting out of the C2 and JTAG code to their own files. I have also split out the code required to drive the EC2 / EC3 /Toolstick bootloader to its own file. This is all leading up to a new release I promise. My todo list is getting much shorter now. Due to the significant improvements I wouldn't even bother with the old 0.4 release or earlier as that will only work with the F310 & F020 and no where near as reliably as the new code should.

The current CVS head should now be stable enough to use.
It has many improvements including target debug testing added to ec2test-any. I have not modified all the tools to prevent CTRL-C or abort from leaving the EC3 active. If you quit a program and the EC3 lights are still on unplug it from the USB for a few seconds then reconnect it. This will prevent possibly damaging the processor with unintended writes when the next connect occurs (yes these processors seem to have a self destruct sequence).
Breakpoints are close to working for all C2 devices. If they don't work for yours let me know and if possible get a data capture of the Silabs IDE setting a breakpoint. There is 8 register locations that differ between C2 micro families that can affect this, I have added valid ones for the F30x and F31x families.
The target debugging test also passes on both the F020 and F120 please let me know about success / failure with other jtag micros.

New CVS commits comming


Happy New year

I have added a tag to cvs 'before-jtag-split'. If you want to get code from CVS I advise you to get it from this tag since the code I'm about to commit although it has significant improvements I have seen some issues with the C2 & EC3 combination. JTAG seems to be fine on either debug adapter.



I've made some great progress.
The tests currently in ec2test-any now pass on both F120 and the F020 as well as the F340. I'm not ready to do a release yet but for those of you who want to live on the bleeding edge it is now in CVS. I still have a few more things to tidy up before a release but it is looking good now. The flash access code has been modified to cope with different sector sizes and with larger address spaces. The xdata access code has been updated to work with C2 devices with external memory interfaces.



Seasons Greetings,

My parts arrived. I have the F340 passing the tests currently in ec2test-any and the F120 can read and write both data and xdata and pass the program counter test now. I should be able to get the F120 flash access working real soon.

For the F120 Flash routines (JTAG) I need to add support for paged SFR's and then to make the flash write code more generic. I have been comparing dumps from the F120 and F020 (which the current JTAG flash write code is based on) and now have a pretty good understanding of what is needed although there is a few command sequences I don't quite understand yet. I have also been comparing these dumps to the JTAG flash programming documentation too fill in some blanks. I'm having a quiet Christmas at home so I hope to find some time in the next week to get this sorted.

One side affect of getting things to work with the F120 is that by making the flash code more generic and removing the F020 specific hard coded byte sequences if should mean that flash access starts to work on other JTAG processors in the family.

Both the F340 and the F120 have extra features above the basic devices and this extra support will be added after the basic functionality for both chips is in place unless someone beets me to it.




In a moment of carelessness I managed to damage my 8051F310 board so no C2 mode testing till I get a new chip. I have ordered a new chip and a couple of other micros for some other projects I'm working at the same time. These extra micros mean I have widened the number of micros I can test and debug EC2DRV with to:

I have decided to postpone the release I was planning this week until I have the new micros which should be about two days time meaning I'll probably do a release in about a weeks time depending on how the debugging goes.
In the mean time stay away from the old ec2drv 0.4 release and use the source from CVS as the version in CSV has many bugs fixed.

I expect to have to spend time debugging to ensure ec2drv works well on all these processors but If it works for this selection It is likely to work with most to the range.

More progress


I've been really busy lately but I have made some progress with ec2drv. There are about 10 bug fixes/enhancements since the last test release which should help it work with more processors. I'm just sorting out a few more minor items before releasing a new test version. It will now print a warning if you use the Auto detect for interface mode because that might have been causing some of the issues seen with some processors. It is now recommended to use --mode=JTAG or --mode=C2 rather than --mode=AUTO or relying on the default which is AUTO.

New test Release


After moving house and unpacking stuff I've finally found time to start working on ec2drv again.

Thanks to those of you providing data captures on the support page this should lead to support of a much larger set of the processor family. I have released a new experimental package on the file release page in sourceforge that contains much better device identification that should be able to uniquely identify chip types rather than just the family. This release also adds an ec2test-any program which should be device independent provided I have the device table correct.

Next on the todo list is making the flash write work properly on all devices. This should be much easier now the device identification has been updated.

New release of experimental package - big improvements


I have released a new version of the experimental package ec2drv-newcdb-23-04-06. I recommend using this release over anything else. It still contains ec2cdb but you should now use newcdb as it is a significant improvement.

USB hotplug for FC4


I have found a way to allow normal users to use an FC4 without root privileges. There are 2 files in ec3-hotplug.tgz that must be placed in /etc/hotplug/usb.
Let us know if this works for other distributions or if you know a better way of handling this. I'm not happy with the script in that is has a fixed sleep time to wait for the kernel to stop fiddling with the device before we change its permissions but at least it avoids having to run everything as root. This is just a hack of the usbcam script that came with fc4.

Website Update


I finally got around to tidying up the webpage and removing some the obsolete information that was just providing clutter.

New Release Package


In addition to the normal ec2drv release package I have added another called ec2drv-experimental which will be used for more frequent updates but they will possibly be less stable but of course more bleeding edge. This is where I'm introducing the newcdb debugger although currently the package still contains the old ec2cdb (modified sdcdb) as well but that code will be depreciated in favor of newcdb.



A new directory has been added to the source tree called newcdb. This is just a working name but it pretty much explains what its working towards. This is similar in functionality to sdcdb from but it provides several new features