Discussion:
[Freetel-codec2] Dumb SM1000 SWD question, where's pin 1?
Stuart Longland
2015-12-12 05:16:55 UTC
Permalink
Hi all,

It's a rainy day here in Brisbane, just perfect weather to experiment
with the SM1000, maybe get some voice announcement code happening. I
figured I'd get my shiny ST-Link/V2 dongle working so I can single-step
and debug the code.

I'm looking at the board, I see there's a 3-pin header for SWD: CN1.
There's nothing I can see though that marks which of those pins is pin 1
(aka SWCLK). The only hint I have is R19 connects to it; I can see a
trace from R19 going to the pin closest to the SELECT/BACK buttons.

Am I on the right track to assume that's SWCLK and that the other end is
SWDIO?

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

------------------------------------------------------------------------------
Steve
2015-12-12 06:06:57 UTC
Permalink
The one on the bottom goes to R19 and top goes to R20 looks like. I'm
looking at the PNG in the repository.
Bottom also shows a wider bar on the silkscreen. Bottom being with
silkscreen "power" to the left (nearest PTT).
Stuart Longland
2015-12-12 06:29:05 UTC
Permalink
Post by Steve
The one on the bottom goes to R19 and top goes to R20 looks like. I'm
looking at the PNG in the repository.
Bottom also shows a wider bar on the silkscreen. Bottom being with
silkscreen "power" to the left (nearest PTT).
Well, now I'm confused.

This is the schematic:
Loading Image...

This is what I see:
Loading Image...

The trace looked to be running from R19 to that top pin, I can see the
thicker bar down the bottom end (sort-of visible in that photo), but I'm
not sure if that's accidental or if that's indeed the convention being used.

I'm used to numbers or a little arrow on the silkscreen. That might be
worthwhile on the next run of SM1000s. :-)

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

------------------------------------------------------------------------------
Steve
2015-12-12 06:38:16 UTC
Permalink
looking at that photo, it's the one on the left. R19 trace sneaks between
the right and middle pins and goes down to the left pin.


On Sat, Dec 12, 2015 at 12:29 AM, Stuart Longland <
Post by Stuart Longland
Post by Steve
The one on the bottom goes to R19 and top goes to R20 looks like. I'm
looking at the PNG in the repository.
Bottom also shows a wider bar on the silkscreen. Bottom being with
silkscreen "power" to the left (nearest PTT).
Well, now I'm confused.
http://www.longlandclan.id.au/~stuartl/freedv/2015/12/12-swd/sm1000-swd.png
http://www.longlandclan.id.au/~stuartl/freedv/2015/12/12-swd/sm1000-swd.jpg
The trace looked to be running from R19 to that top pin, I can see the
thicker bar down the bottom end (sort-of visible in that photo), but I'm
not sure if that's accidental or if that's indeed the convention being used.
I'm used to numbers or a little arrow on the silkscreen. That might be
worthwhile on the next run of SM1000s. :-)
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Stuart Longland
2015-12-12 06:46:32 UTC
Permalink
Post by Steve
looking at that photo, it's the one on the left. R19 trace sneaks
between the right and middle pins and goes down to the left pin.
Ahh, gotcha. Okay, I'll plug 'er in and see what I get.

Hopefully not smoke signals. :-)

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

------------------------------------------------------------------------------
Stuart Longland
2015-12-12 07:32:50 UTC
Permalink
Post by Stuart Longland
Post by Steve
looking at that photo, it's the one on the left. R19 trace sneaks
between the right and middle pins and goes down to the left pin.
Ahh, gotcha. Okay, I'll plug 'er in and see what I get.
Hopefully not smoke signals. :-)
Okay, took a bit of tinkering, but here's the full detail.

You'll need a recent OpenOCD, likely not the one shipped as a binary in
Debian/Ubuntu. I'm doing this on a Gentoo host, and use
dev-embedded/openocd-9999 which pulls source from their git repository.

You'll also need a cable that exposes the SWD pins from the JTAG header.
The three pins you need are:

Pin 7: SWDIO
Pin 8: GND
Pin 9: SWCLK

Loading Image...
shows how to connect this cable. I've actually broken out the other
three signals as well. SWDIO is the green wire, SWCLK is the blue wire,
and the white/orange one is the ground.

Also visible but not used is MCU VDD (orange, pin 1), TRACESWO (brown,
pin 13) and nRST (white/green, pin 15).

Open up two terminal sessions. In the first, create a file in your
local working directory called openocd.cfg with the following content
(thanks to Glen English for getting me started with the ST-Link/V2):

source [find interface/stlink-v2.cfg]
source [find target/stm32f4x.cfg]
reset_config none separate

That last line is important, since we don't connect nRST to the target
on the SM1000.
Post by Stuart Longland
Open On-Chip Debugger 0.10.0-dev-00120-g7a8915f (2015-11-25-18:49)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 1.555905
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10016413
Info : flash size = 1024kbytes
undefined debug reason 7 - target needs reset
stm32f4x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0802cdb0 msp: 0x20020000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
adapter speed: 4000 kHz
GNU gdb (Gentoo 7.8 vanilla) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
<http://bugs.gentoo.org/>.
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from projects/sm1000/codec2/stm32/sm1000.elf...done.
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: Can not parse XML target description; XML support was disabled at compile time
warning: Can not parse XML memory map; XML support was disabled at compile time
0x00000000 in ?? ()
(gdb) monitor reset init
stm32f4x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0802cdb0 msp: 0x20020000
Unable to match requested speed 8000 kHz, using 4000 kHz
Unable to match requested speed 8000 kHz, using 4000 kHz
adapter speed: 4000 kHz
Now, set your breakpoints, when you're happy, use `c` to continue execution.
Post by Stuart Longland
(gdb) break main
Breakpoint 1 at 0x802baa8: file src/sm1000_main.c, line 256.
(gdb) c
Continuing.
Breakpoint 1, main () at src/sm1000_main.c:256
warning: Source file is more recent than executable.
256 int main(void) {
(gdb) list
251 /* Load from the latest image */
252 memcpy(&prefs, &image[newest], sizeof(prefs));
253 return 0;
254 }
255
256 int main(void) {
257 struct freedv *f;
258 int nin, nout, i;
259 int n_samples, n_samples_16k;
260
You should be able to stop the program anywhere by hitting ^C, inspect
variables, adjust breakpoints, etc. There are also front-ends to gdb if
that's preferred.

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

------------------------------------------------------------------------------
glen english
2015-12-12 07:55:51 UTC
Permalink
Stuart, get it the wrong way around and worst case is it won't work...
Post by Stuart Longland
Post by Steve
looking at that photo, it's the one on the left. R19 trace sneaks
between the right and middle pins and goes down to the left pin.
Ahh, gotcha. Okay, I'll plug 'er in and see what I get.
------------------------------------------------------------------------------
Stuart Longland
2015-12-12 08:18:09 UTC
Permalink
Post by glen english
Stuart, get it the wrong way around and worst case is it won't work...
Yeah, figured as much. However, would it then be "not working" because
I wired the connections to the SM1000 wrong, or "not working" because I
buggered up my JTAG break-out cable.

There was a good chance of the latter, since I basically cannibalised my
old serial AVR programmer for its pin header sockets.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

------------------------------------------------------------------------------
David Rowe
2015-12-12 20:34:39 UTC
Permalink
Hi Stuart,

Nice work documenting that, I haven't used openocd myself so nice to
have an alternative.

I have added a note to the Rev G change log to add silk screen labels to
the CN1 pins.

Cheers,

David
Post by Stuart Longland
Post by Stuart Longland
Post by Steve
looking at that photo, it's the one on the left. R19 trace sneaks
between the right and middle pins and goes down to the left pin.
Ahh, gotcha. Okay, I'll plug 'er in and see what I get.
Hopefully not smoke signals. :-)
Okay, took a bit of tinkering, but here's the full detail.
You'll need a recent OpenOCD, likely not the one shipped as a binary in
Debian/Ubuntu. I'm doing this on a Gentoo host, and use
dev-embedded/openocd-9999 which pulls source from their git repository.
You'll also need a cable that exposes the SWD pins from the JTAG header.
Pin 7: SWDIO
Pin 8: GND
Pin 9: SWCLK
http://www.longlandclan.id.au/~stuartl/freedv/2015/12/12-swd/sm1000-stlinkv2-swd.jpg
shows how to connect this cable. I've actually broken out the other
three signals as well. SWDIO is the green wire, SWCLK is the blue wire,
and the white/orange one is the ground.
Also visible but not used is MCU VDD (orange, pin 1), TRACESWO (brown,
pin 13) and nRST (white/green, pin 15).
Open up two terminal sessions. In the first, create a file in your
local working directory called openocd.cfg with the following content
source [find interface/stlink-v2.cfg]
source [find target/stm32f4x.cfg]
reset_config none separate
That last line is important, since we don't connect nRST to the target
on the SM1000.
Post by Stuart Longland
Open On-Chip Debugger 0.10.0-dev-00120-g7a8915f (2015-11-25-18:49)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 1.555905
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10016413
Info : flash size = 1024kbytes
undefined debug reason 7 - target needs reset
stm32f4x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0802cdb0 msp: 0x20020000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
adapter speed: 4000 kHz
GNU gdb (Gentoo 7.8 vanilla) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
<http://bugs.gentoo.org/>.
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from projects/sm1000/codec2/stm32/sm1000.elf...done.
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: Can not parse XML target description; XML support was disabled at compile time
warning: Can not parse XML memory map; XML support was disabled at compile time
0x00000000 in ?? ()
(gdb) monitor reset init
stm32f4x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0802cdb0 msp: 0x20020000
Unable to match requested speed 8000 kHz, using 4000 kHz
Unable to match requested speed 8000 kHz, using 4000 kHz
adapter speed: 4000 kHz
Now, set your breakpoints, when you're happy, use `c` to continue execution.
Post by Stuart Longland
(gdb) break main
Breakpoint 1 at 0x802baa8: file src/sm1000_main.c, line 256.
(gdb) c
Continuing.
Breakpoint 1, main () at src/sm1000_main.c:256
warning: Source file is more recent than executable.
256 int main(void) {
(gdb) list
251 /* Load from the latest image */
252 memcpy(&prefs, &image[newest], sizeof(prefs));
253 return 0;
254 }
255
256 int main(void) {
257 struct freedv *f;
258 int nin, nout, i;
259 int n_samples, n_samples_16k;
260
You should be able to stop the program anywhere by hitting ^C, inspect
variables, adjust breakpoints, etc. There are also front-ends to gdb if
that's preferred.
Regards,
------------------------------------------------------------------------------
glen english
2015-12-14 02:35:00 UTC
Permalink
nice one STuart good tutorial
Post by Steve
looking at that photo, it's the one on th
------------------------------------------------------------------------------
Steve
2015-12-12 06:42:57 UTC
Permalink
On Sat, Dec 12, 2015 at 12:29 AM, Stuart Longland <
Post by Stuart Longland
Post by Steve
The one on the bottom goes to R19 and top goes to R20 looks like. I'm
looking at the PNG in the repository.
Bottom also shows a wider bar on the silkscreen. Bottom being with
silkscreen "power" to the left (nearest PTT).
Well, now I'm confused.
http://www.longlandclan.id.au/~stuartl/freedv/2015/12/12-swd/sm1000-swd.png
http://www.longlandclan.id.au/~stuartl/freedv/2015/12/12-swd/sm1000-swd.jpg
The trace looked to be running from R19 to that top pin, I can see the
thicker bar down the bottom end (sort-of visible in that photo), but I'm
not sure if that's accidental or if that's indeed the convention being used.
I'm used to numbers or a little arrow on the silkscreen. That might be
worthwhile on the next run of SM1000s. :-)
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Loading...