Hi huys.
I got some progress here. But it still looks very confusing…
As for me it looks like reset sequence or its timing is wrong.
I’ve hardcode frequency for simplicity:
diff --git a/src/jtag/drivers/ftdi.c b/src/jtag/drivers/ftdi.c
- freq = mpsse_set_frequency(mpsse_ctx, 1000);
+ freq = mpsse_set_frequency(mpsse_ctx, 150000);
but keep adapter_khz 1000.
1) I can program nrf51 flash by command:
./openocd -f ftdi.cfg -f nrf51.cfg -c init -c "flash write_image erase
ble_app_hrs_uart_xxaa.hex" -c shutdown
➜ ./openocd -f ftdi.cfg -f nrf51.cfg -c init -c "flash write_image erase
/Users/anpilog/Downloads/nrf51_sdk_v6_0_0_43681/nrf51822/Board/pca10001/s110/ble_app_hrs/gcc/_build/ble_app_hrs_uart_xxaa.hex"
-c shutdown
Open On-Chip Debugger 0.9.0-dev-00098-ge03eb89-dirty (2014-07-20-09:30)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
swd
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x0bb11477
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
auto erase enabled
Info : nRF51822-QFAA(build code: CA/C0) 256kB Flash
wrote 71680 bytes from file
/Users/anpilog/Downloads/nrf51_sdk_v6_0_0_43681/nrf51822/Board/pca10001/s110/ble_app_hrs/gcc/_build/ble_app_hrs_uart_xxaa.hex
in 10.057960s (6.960 KiB/s)
shutdown command invoked
BUT:
- openocd loses nRF51 when talk to it first time after power cycle:
➜ ./openocd -f ftdi.cfg -f nrf51.cfg -c init -c "flash write_image erase
/Users/anpilog/Downloads/nrf51_sdk_v6_0_0_43681/nrf51822/Board/pca10001/s110/ble_app_hrs/gcc/_build/ble_app_hrs_uart_xxaa.hex"
-c shutdown
Open On-Chip Debugger 0.9.0-dev-00098-ge03eb89-dirty (2014-07-20-09:30)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
swd
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x0bb11477
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
Error: nrf51.cpu -- clearing lockup after double fault
Polling target nrf51.cpu failed, GDB will be halted. Polling again in 100ms
Polling target nrf51.cpu succeeded again, trying to reexamine
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
auto erase enabled
Info : nRF51822-QFAA(build code: CA/C0) 256kB Flash
wrote 71680 bytes from file
/Users/anpilog/Downloads/nrf51_sdk_v6_0_0_43681/nrf51822/Board/pca10001/s110/ble_app_hrs/gcc/_build/ble_app_hrs_uart_xxaa.hex
in 9.992567s (7.005 KiB/s)
shutdown command invoked
- "reset init” command doesn’t works as expected:
➜ ./openocd -f ftdi.cfg -f nrf51.cfg -c init -c "reset init”:
Open On-Chip Debugger 0.9.0-dev-00098-ge03eb89-dirty (2014-07-20-09:30)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
swd
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x0bb11477
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
TARGET: nrf51.cpu - Not halted
in procedure 'reset'
in procedure 'ocd_bouncer'
in procedure ‘reset'
see full debug output at: http://pastebin.com/ywtyUq7e
2) GDB session doesn’t work:
➜ arm-none-eabi-gdb
/Users/anpilog/Downloads/nrf51_sdk_v6_0_0_43681/nrf51822/Board/pca10001/s110/ble_app_hrs/gcc/_build/ble_app_hrs_uart_xxaa.out
GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140228-cvs
Copyright (C) 2013 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-apple-darwin10
--target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/Users/anpilog/Downloads/nrf51_sdk_v6_0_0_43681/nrf51822/Board/pca10001/s110/ble_app_hrs/gcc/_build/ble_app_hrs_uart_xxaa.out...done.
(gdb) target remote :3333
Remote debugging using :3333
Remote connection closed
(gdb)
➜ ./openocd -f ftdi.cfg -f nrf51.cfg -c init
Open On-Chip Debugger 0.9.0-dev-00098-ge03eb89-dirty (2014-07-20-09:30)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
swd
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x0bb11477
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Warn : Unknown device (HWID 0x00000000)
Error: Failed to read memory and, additionally, failed to find out where
Error: Couldn't read code page size
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to
prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected
Full debug output is here:
http://pastebin.com/20iy6ZHq
On 20 Jul, 2014, at 1:45 pm, Andrii Anpilogov <[email protected]> wrote:
> Hi Angus,
>
> See my reply below.
>
> On 20 Jul, 2014, at 12:36 pm, Angus Gratton <[email protected]> wrote:
>
>> Hi Andrii,
>>
>> Sorry to hear it's not working. :(
>>
>> On Sun, Jul 20, 2014 at 10:00:37AM +0800, Andrii Anpilogov wrote:
>>> Hi Angus,
>>>
>>> Just noticed you removed
>>> https://gist.github.com/projectgus/224f06d0276affc69826
>>
>> I revised it, but the previous revision is there under the Revisions tab:
>>
>> https://gist.github.com/projectgus/224f06d0276affc69826/176d4954237c0e343852ba76ef2788cee0f1f569
>>
> I’m going to try it and post results.
>
>> Interested to hear if it makes a difference.
>>
>> Can you please try with the nrf51.cfg config file from here as well?
>>
> I’ve tried. They are identical and both don’t work.
>
>> http://openocd.zylin.com/#/c/2116/2
>>
>> I think they're probably identical, but it eliminates one possible variable.
>>
>>> On 20 Jul, 2014, at 9:54 am, Andrii Anpilogov <[email protected]> wrote:
>>>> Note:
>>>> My FTDI debugger has proper multiplexed SWDIO.
>>
>> Can you explain what this means please? Do you mean there's a
>> tri-state buffer between TDI and SWDIO, rather than the resistor hack?
>> Does this FTDI adapter work in SWD mode with other targets?
>>
> You are correct. I have tri-state buffer.
> It perfectly works with stm32f1x and as you can see it’s able to talk to
> nRF51 too.
> But later during the communication it fails.
>
>> Cheers,
>>
>>
>> Angus
>
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
