Hi, As you have likely noticed, we had to postpone 0.9.0 release and there's still some work to do before it can happen. Let me explain what's going on and how you can help.
One of the major release goals for 0.9.0 is better SWD support, and we've got some very negative early feedback in August-September regarding that. The most visible issues are following: 1. FTDI and J-Link do not allow to continue talking to a target after any single failure; 2. CMSIS-DAP driver is unusably slow; 3. Atmel SAM4L (and other similar devices) do not work at all after reset, even with Atmel's own debug adapter (EDBG, using CMSIS-DAP); 4. SWD WAIT handling is not implemented for low-level drivers, so e.g. nRF51 can't be flashed with a simple and efficient async loader. Considering all that, letting 0.9.0 out wouldn't be a wise move, as OpenOCD users should be able to count on official release versions to work reliably and be suitable for production environments. I've spent some time now working on the issues mentioned and here's what I came up with so far: Number 1 should be covered with http://openocd.zylin.com/#/c/2371 , I tried hard to disrupt communication by various means but so far it seems rock-solid now provided that the adapter itself is not abused or disconnected from the host. Please do testing on your side and report the results, I might have missed some usecases. While we were waiting for somebody to fix SWD in general, we got reports that some J-Link versions do not work at all in this mode, and luckily Segger was friendly enough to provide us with the information needed to fix it, see http://openocd.zylin.com/2331 . In particular, this makes nRF51 USB dongle work as expected. Please also try and report, if you have any J-Link hardware handy. Number 2 should be covered by http://openocd.zylin.com/2356 . It now works reasonably well with "mbed" and "ulink me" CMSIS-DAP adapters I have for testing, but unfortunately Atmel's EDBG still has some issues. I expect them to be easy enough to fix, and I think that's necessary to do before the release. If you feel like giving it a try, do not hesitate, as I'm waiting for the hardware to arrive here and so can't do it myself yet. Number 3 might be solved by the patches mentioned earlier, again, more testing and a bit debugging are needed here. Number 4 should IMHO be postponed as it'd be an invasive change to the way things currently work, and it's not as pressing. We have WAIT handling working with ST-Link (thanks to extensive work on Sigrok SWD decoder and debugging done by Angus) and CMSIS-DAP (handled on firmware level), so if somebody really needs that, he or she can just get a suitable adapter. Other area that would be nice to get feedback about is RTOS support. FreeRTOS users will hopefully find http://openocd.zylin.com/2347 handy, and ChibiOS users should check this branch: http://openocd.zylin.com/#/c/2352 (it's also of interest to other RTOS implementors as it introduces a concept of "optional" symbols, for better or worse is yet to be determined). Also, http://openocd.zylin.com/2301 needs a closer look. Having all those handled by the upcoming release would be cool. If there're any Cortex-A developers around, you might be interested to try http://openocd.zylin.com/2344 , and to help fix http://openocd.zylin.com/#/c/2345/ . Some testing or code review with ARM11 is needed for http://openocd.zylin.com/#/c/2043/ . So far I've mostly mentioned the work I'm personally involved in, as my view is obviously biased. If you have something to add here to the list, please do, any feedback is appreciated as OpenOCD is really a community-driven project now. HTH, and happy hacking! -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[email protected] ------------------------------------------------------------------------------ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
