- Wed Jul 01, 2015 12:28 pm
#22177
Althouth it seems that OpenOCD support both SWD and SWIM (if my readings are not wrong), it seems that SWIM is not as much documented as SWD, and it also only backed only my STM, no other ARMs are using it. Am I right ?
- Wed Jul 01, 2015 6:29 pm
#22199
You're right, as far as I know SWIM is a proprietary STMicro protocol not an ARM standard. SWD is an ARM standard, which means unlike JTAG it has quite a lot of ARM-specific assumptions about the debug port layout baked into it (ie the layer above the on-the-wire signalling, implemented in openocd/whatever).
So, sadly, there's no easy way to rewire a JTAG port as SWD. Even if Espressif modified their silicon there's not really an easy way to have an Xtensa debug port look like an SWD-compatible ARMv5 debug port. They could maybe do 'reduced pin count JTAG' though, which is yet another two wire protocol!
For my 2c, I've worked a lot with SWD and JTAG and although I prefer SWD on ARM, you get used to the extra wires. Besides, with a gdb stub on xtensa you can have 'zero-wire' debugging!
martinayotte wrote:Althouth it seems that OpenOCD support both SWD and SWIM (if my readings are not wrong), it seems that SWIM is not as much documented as SWD, and it also only backed only my STM, no other ARMs are using it. Am I right ?
You're right, as far as I know SWIM is a proprietary STMicro protocol not an ARM standard. SWD is an ARM standard, which means unlike JTAG it has quite a lot of ARM-specific assumptions about the debug port layout baked into it (ie the layer above the on-the-wire signalling, implemented in openocd/whatever).
So, sadly, there's no easy way to rewire a JTAG port as SWD. Even if Espressif modified their silicon there's not really an easy way to have an Xtensa debug port look like an SWD-compatible ARMv5 debug port. They could maybe do 'reduced pin count JTAG' though, which is yet another two wire protocol!
For my 2c, I've worked a lot with SWD and JTAG and although I prefer SWD on ARM, you get used to the extra wires. Besides, with a gdb stub on xtensa you can have 'zero-wire' debugging!
- Wed Jul 01, 2015 9:25 pm
#22208
Of course ! Or maybe also "brain-wave wireless wires" , but that just a dream
Back to the subject, if I wish to debug something that is using the serial port, I would prefer having to spend some extra SWD wires elsewhere instead of using the serial port itself.
(so that gdb-stub should be versatile enough to allow that)
projectgus wrote:Besides, with a gdb stub on xtensa you can have 'zero-wire' debugging!
Of course ! Or maybe also "brain-wave wireless wires" , but that just a dream
Back to the subject, if I wish to debug something that is using the serial port, I would prefer having to spend some extra SWD wires elsewhere instead of using the serial port itself.
(so that gdb-stub should be versatile enough to allow that)
- Thu Jul 02, 2015 12:15 am
#22220
Moin,
if I get my stub running at user interrupt level it should be easy.
I/O of my gdb stub is abstracted to
When running at user interrupt level the uart ints should be usable.
Or some kind of software serial or even tcp/udp maybe possible.
Some kernels use a protocol layer on serial that mixes user data and debug data.
AFAIK tcp/udp needs the main XTOS/SDK task loop to run. That may be tricky.
Maybe easier to hook up a second esp8266 as a debug probe.
Timer driven software serial?
Cal
martinayotte wrote:projectgus wrote:Back to the subject, if I wish to debug something that is using the serial port, I would prefer having to spend some extra SWD wires elsewhere instead of using the serial port itself.
(so that gdb-stub should be versatile enough to allow that)
Moin,
if I get my stub running at user interrupt level it should be easy.
I/O of my gdb stub is abstracted to
- prepare i/o on enter stub - currently disables uart interrupts
- read char
- write char
- flush chars
- restore i/o on leaving stub - re-enables uart interrupt
When running at user interrupt level the uart ints should be usable.
Or some kind of software serial or even tcp/udp maybe possible.
Some kernels use a protocol layer on serial that mixes user data and debug data.
AFAIK tcp/udp needs the main XTOS/SDK task loop to run. That may be tricky.
Maybe easier to hook up a second esp8266 as a debug probe.
Timer driven software serial?
Cal
