Hi Tomas, On 19/11/18 9:34 pm, Tomas Vanek wrote: > yes we all overlooked the pitfall that CC2538 belongs to the cc26xx family. > Can you please test with the last line of tcl/target/cc2538.cfg > changed to > source [find target/ti_cc26xx.cfg] > > I have no idea if CC2538 has any internal flash and if it will be > properly handled by the new flash driver. The old config had no flash > defined, so you should get the same functionality as before.
Yes I did try that, OpenOCD seemed to connect to the target, but then refused to allow gdb to connect. I can do some more testing tomorrow when I'm back at work (might hand-build OpenOCD git HEAD instead of using the Gentoo ebuild, since it looks like I'll need to run two versions). For what it's worth, the JTAG hardware I'm using is a clone XDS100v3 JTAG dongle (Olimex version) and the target board is a custom design not dissimilar to the CC2538+CC2592 reference design from TI. My config is minimal: > source [find interface/ftdi/xds100v3.cfg] > transport select jtag > source [find target/cc2538.cfg] > adapter_khz 4000 > init > ftdi_set_signal PWR_RST 1 > jtag arp_init I did try early on to use my ST-Link v2, but refused to talk (did the same for a NXP LPC810 too, I think it just doesn't like non-ST parts). I have since had to revert back to 0.10.0 after all, because even re-instating the cc26xx.cfg config file, breakpoints didn't work. I could hit ^C and pause the application, but then if I set a breakpoint a few lines later in my code, regardless of what instructions took place in between, the breakpoint would never trigger. `finish` also didn't work. Flash programming through OpenOCD has unfortunately never worked with the CC2538, and the latest code didn't change that. So my workflow is to start Uniflash, flash the code with that, then power-cycle the dev board (Uniflash leaves the JTAG interface in a funny state that OpenOCD doesn't like) and connect OpenOCD/gdb. Cumbersome, but it works, in spite of Uniflash's insufferable idiosyncrasies. I've used OpenOCD with ST parts, as well as with the Nordic nRF52840, so I do prefer to use that over a proprietary tool. nRF52840 flash programming seems broken in the 0.10.0 release but it worked in the git HEAD build I did the other day. ST parts for me have always worked. Personally, I think TI could have saved themselves a lot of trouble just supporting OpenOCD and maybe made Uniflash just fire up OpenOCD behind the scenes and talk to it via its `telnet` interface: they'd get support for lots more debuggers for free, gdb proxy thrown in and a more reliable experience to boot. But I digress… I did see some patches to support the NOR flash on the CC2538, and it was on my list somewhere to have a closer look at those and maybe see if I could get them working with current OpenOCD, but when one is on a tight deadline, one just reaches for what works for the present. Perhaps next year, I might get myself a cheap CC2538 dev board (the Zolertia Fireflys are reasonably priced) for home and see if I can refine my dev environment a bit and give a bit back to OpenOCD in the process. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
