Discussion:
[OpenOCD-devel] HLA(STlink)-access and 'mw'
Uwe Bonnes
2015-04-09 11:36:29 UTC
Permalink
Hello,

the patch "tcl: Add default hooks for STM32F3x"
(8d80a25410bb76670c7fcf780b624212bd769e47) added a "mwh" access.

Running on a F334 discovery with lastest STLink firmware gives:
(gdb) mon reset init
Unable to match requested speed 1000 kHz, using 950 kHz
Unable to match requested speed 1000 kHz, using 950 kHz
adapter speed: 950 kHz
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08004624 msp: 0x20000608
tcl/target/stm32f3x.cfg:108: Error:
in procedure 'reset'
in procedure 'ocd_bouncer'
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file "embedded:startup.tcl", line 246
in procedure 'stm32f3x.cpu' called at file "embedded:startup.tcl", line 368
in procedure 'ocd_bouncer'
in procedure 'stm32f3x_default_reset_init'
in procedure 'mwh' called at file "tcl/target/stm32f3x.cfg", line 108

It seems that 'mwh' access is noy supported for the STLink. Is that the case
or do I something wrong?

Thanks
--
Uwe Bonnes ***@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Paul Fertser
2015-04-09 12:22:13 UTC
Permalink
Hello,
Post by Uwe Bonnes
the patch "tcl: Add default hooks for STM32F3x"
(8d80a25410bb76670c7fcf780b624212bd769e47) added a "mwh" access.
Thank you for the report, I hope it's fixed with
http://openocd.zylin.com/2702 now.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:***@gmail.com
Uwe Bonnes
2015-04-09 12:50:34 UTC
Permalink
Post by Uwe Bonnes
the patch "tcl: Add default hooks for STM32F3x"
(8d80a25410bb76670c7fcf780b624212bd769e47) added a "mwh" access.
Paul> Thank you for the report, I hope it's fixed with
Paul> http://openocd.zylin.com/2702 now.

First, some culprit is with me as I reviewed ths patch and didn't notice the
problem.

Second, the STLink know how to write bytes. However in the above
offending case
mwb 0x40021003 0x01 ;# RCC_CR[31:16] = PLLON
doesn't work neither. Shouldn't mwb work?

The comment in stlink_usb_write_mem() also says:
/* the stlink only supports 8/32bit memory read/writes
* honour 32bit, all others will be handled as 8bit access */

Why isn't the mww broken down as two mwb?

Thanks
--
Uwe Bonnes ***@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe Bonnes
2015-04-09 13:50:48 UTC
Permalink
...
Uwe> Why isn't the mww broken down as two mwb?

Digging deeper, both mwh and mwb returned a Verify error, as PLLON set
PLLRDY and readback got 0x3(PLLRDY|PLLON) versus 0x1 (PLLON) written.

Both
mwb 0x40021003 0x03 ;# RCC_CR[31:24] = PLLON. Read PLLON|PLLRCY
and
mwb 0x40021002 0x0300 ;# RCC_CR[31:16] = PLLON. Read PLLON|PLLRCY

succeed as expected. I have updated #2702.

Bye
--
Uwe Bonnes ***@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Paul Fertser
2015-04-09 14:02:24 UTC
Permalink
Post by Uwe Bonnes
...
Uwe> Why isn't the mww broken down as two mwb?
Digging deeper, both mwh and mwb returned a Verify error, as PLLON set
PLLRDY and readback got 0x3(PLLRDY|PLLON) versus 0x1 (PLLON) written.
Both
mwb 0x40021003 0x03 ;# RCC_CR[31:24] = PLLON. Read PLLON|PLLRCY
and
mwb 0x40021002 0x0300 ;# RCC_CR[31:16] = PLLON. Read PLLON|PLLRCY
succeed as expected. I have updated #2702.
Why is it better than mmw? Does mmw not work due to a verify error
either?
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:***@gmail.com
Andreas Fritiofson
2015-04-09 18:12:01 UTC
Permalink
On Thu, Apr 9, 2015 at 3:50 PM, Uwe Bonnes <
Post by Uwe Bonnes
...
Uwe> Why isn't the mww broken down as two mwb?
Digging deeper, both mwh and mwb returned a Verify error, as PLLON set
PLLRDY and readback got 0x3(PLLRDY|PLLON) versus 0x1 (PLLON) written.
WTF is the STLink doing here? Why readback a write?? Is the firmware or our
driver the culprit?

/Andreas
Uwe Bonnes
2015-04-09 18:37:47 UTC
Permalink
Andreas> On Thu, Apr 9, 2015 at 3:50 PM, Uwe Bonnes <
Andreas> ***@elektron.ikp.physik.tu-darmstadt.de> wrote:

Andreas> ...     Uwe> Why isn't the mww broken down as two mwb?

Andreas> Digging deeper, both mwh and mwb returned a Verify error,
Andreas> as PLLON set PLLRDY and readback got 0x3(PLLRDY|PLLON) versus
Andreas> 0x1 (PLLON) written.

Andreas> WTF is the STLink doing here? Why readback a write?? Is the
Andreas> firmware or our driver the culprit?

At first, it is clearly the firmware. The reply sent a JTAG Status code
#define STLINK_JTAG_WRITE_VERIF_ERROR 0x0D

Otherwise OpenOCD doesn't know of this error and so perhaps reacts
inadequat. Maybe openocd should simply treat STLINK_JTAG_WRITE_VERIF_ERROR
as success.

I downgraded the firmware on a F4 Discovery to something really old and still
the error happens:
...
Info : 253 4 stlink_usb.c:515 stlink_usb_version(): STLINK v2 JTAG v21 API v2 SWIM v0 VID 0x0483 PID 0x3748
...
Debug: 728 4942 hla_target.c:766 adapter_write_memory(): adapter_write_memory 0x40023808 1 1
Debug: 729 4943 stlink_usb.c:394 stlink_usb_error_check(): unknown/unexpected STLINK status code 0xd
Debug: 730 4943 command.c:628 run_command(): Command failed with error code -4
User : 731 4943 command.c:546 command_print(): in procedure 'reset'
in procedure 'ocd_bouncer'
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file "embedded:startup.tcl", line 246
in procedure 'stm32f4x.cpu' called at file "embedded:startup.tcl", line 368
in procedure 'ocd_bouncer'
in procedure 'mwb'

Bye
--
Uwe Bonnes ***@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Loading...