Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

My DAPLink interface does not reset target (nRF51822) after download program. #166

Closed
iotmember opened this issue Oct 9, 2016 · 17 comments
Labels

Comments

@iotmember
Copy link
Contributor

Hi.
I have a problem with DAPLink interface.
DAPLink connect to nRF51822 over SWD (SWDCLK, SWDIO) and TX, RX.
If I use drag-drop method with MSD to program firmware to target, target will be reset after done (Automation-allowed=1, Auto Reset=1).
But after I download program to target (DAP-HID), target will not be reset!
That is my problem. Please help me! Thanks

@c1728p9
Copy link
Contributor

c1728p9 commented Oct 9, 2016

Hi @iotvietmember, what are you using to program over DAP-HID? Is it pyOCD, OpenOCD or some other tool? The DAP-HID endpoint provides a debugging interface that is completely controlled by the PC. Whatever tool you are using must reset the target.

@iotmember
Copy link
Contributor Author

Thanks for your reply.
I am using Keil uVision4. I checked Reset and Run in Setting
With Cmsis-dap, everything is ok.
Thanks

@c1728p9
Copy link
Contributor

c1728p9 commented Oct 9, 2016

Good to hear. Should this issue be closed then?

@iotmember
Copy link
Contributor Author

Why?

@c1728p9
Copy link
Contributor

c1728p9 commented Oct 9, 2016

Are you having problems with Keil uVision 4?

@iotmember
Copy link
Contributor Author

May be.
But I am also using CMSIS-DAP and it works fine with Keil

@iotmember
Copy link
Contributor Author

Thanks c1728p9!
I used pyOCD to program code over DAPLink and it worked well.
Perhaps, Keil has not worked well yet with DAPLink

@c1728p9
Copy link
Contributor

c1728p9 commented Oct 24, 2016

@iotvietmember are you still having problem with Keil? Keil should work as well as pyOCD does. It sounds like you found a setting in Keil/uVision that solved your problem.

@iotmember
Copy link
Contributor Author

@c1728p9 No, I am still having problem with Keil. I tried to use some settings in Keil/uVision but this problem is not OK

@c1728p9
Copy link
Contributor

c1728p9 commented Oct 25, 2016

When using uVision what reset mode are you using? Autodetect, HW RESET, SYSRESETREQ or VECTRESET? Also, you mention that CMSIS-DAP works fine with Keil. Can you clarify what you mean by this? DAPLink implements the CMSIS-DAP protocol. Is this another version of firmware?

@iotmember
Copy link
Contributor Author

I used all reset options, such as Autodetect, HW RESET, SYSRESETREQ or VECTRESET but do not successful.
I am using nRF51822 and this chip have not individual reset pin. SWDIO/Reset is a pin.

@OSHChip-Owner
Copy link

OSHChip-Owner commented Oct 25, 2016

I've been seeing the same issue as iotvietmember.
I was using the V5.14 eval version of Keil uV with DAPLink version 0242
I upgraded Keil uV5 to the latest 5.21a and still have the same problem.
I am using 0242_release_package_eab079b8.zip , using 0242_lpc11u35_archble_0x0000.bin
as it is the closest to my hardware OSHChip_CMSIS_DAP_V1.0

After loading the firmware into the LPC11U35 and disconnecting and reconnecting the USB cable, while holding the reset button, I copy the two files to the DAPLink drive:
auto_on.cfg
auto_rst.cfg

The details.txt contains the following:

DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 90090000189cea9700000000000000000000000097969902
HIC ID: 97969902
Auto Reset: 1
Automation allowed: 1
Daplink Mode: Interface
Interface Version: 0242
Git SHA: eab079b
Local Mods: 0
USB Interfaces: MSD, CDC, HID
Interface CRC: 0xc52d7d56

Here is what I am seeing:
If I create a .hex file and drag-drop it on the MSD drive, the nRF51822 is programmed, and the application is started.

If I run the pyocd.py utility:
python "c:\Program Files (x86)\Python27\Lib\site-packages\pyOCD\tools\pyocd.py"
it runs correctly and allows me to communicate with the nRF51822 via the available commands.

In Keil (V5.21a most recent) in the "Options for Target"->Utilities tab-> Settings ,
I have the following:
Erase Full Chip is selected
Program - Checked
Verify - Checked
Reset and Run - Checked
RAM for Algorithm: start at 0x20000000 Size 0x1000
Programming Algorithm: nRF51xxx size 2M On-Chip Flash address range 00000000H - 001FFFFFH

When I download to the target from within Keil (Download Icon or Menu->Flash->Download)
The HID LED flashes on the SWD programmer, and when it completes the Keil Output window
contains the following:

*** Using Compiler 'V5.06 update 3 (build 300)', folder: 'C:\Keil_v5\ARM\ARMCC\Bin'
Rebuild target 'Target 1'
assembling arm_startup_nrf51.s...
compiling system_nrf51.c...
compiling Test_tripple_blink.c...
linking...
Program Size: Code=5048 RO-data=224 RW-data=80 ZI-data=4368
FromELF: creating hex file...
".\Build\Test_tripple_blink.axf" - 0 Error(s), 0 Warning(s).
Build Time Elapsed: 00:00:01
Load "D:\2016\uV5_OSHChip\Test_tripple_blink\Build\Test_tripple_blink.axf"
Full Chip Erase Done.
Programming Done.
Verify OK.
Application running ...
Flash Load finished at 20:40:04

Although the message above ends with "Application running ..." , the nRF51822
is not running the program (yet).

Pressing and releasing the reset button on the SWD programmer will start
the program in the target nRF51822.

I have also tried it with the "Reset and Run" un-checked with the same behavior.

Earlier in the thread, @c1728p9 asked about reset mode. I have tried all 4 options:
Autodetect, HW RESET, SYSRESETREQ or VECTRESET
and the behavior does not change. Please note though, that this setting is part of the Debug settings, and there is no similar option in for Flash Download, just "Reset and Run".

@iotmember
Copy link
Contributor Author

@OSHChip-Owner Your problem is the same issue as me

@OSHChip-Owner
Copy link

@iotvietmember Yes I know, as I have written at the top of my comment.

The purpose of my comment is to give much more details to @c1728p9 to
help in identifying the cause.
Personally, I suspect that the problem is within Keil, and it is not sending
the correct commands to the programmer, and so this issue might not be
something the DAPLink developers can fix.

@c1728p9 c1728p9 added the bug label Nov 18, 2016
@c1728p9
Copy link
Contributor

c1728p9 commented Nov 22, 2017

Hi @iotvietmember and @OSHChip-Owner, I took a look at this and was able to reproduce the problem. In uVision when the Reset and Run option is set and you program via Menu->Flash->Download uVision tries to reset the nrf51 by setting the nRESET pin low using the DAP_SWJ_Pins command (confirmed by capturing wireshark logs) regardless of reset options. The problem is that the nrf51 doesn't have a reset pin so this does nothing.

Additionally, as a test I created a build for the ArchBLE which does an nrf51 specific reset when it would normally set the reset pin low. This image can be found here. Unfortunately, there is not a generic DAPLink fix for this, as this change will break reset on other targets.

I opened a tick on silver.arm.com for this since Reset and Run is always using a pin reset rather than the selected reset type.

@OSHChip-Owner
Copy link

Hi @c1728p9 , Thanks for looking into this. I downloaded the image you created, and can confirm that downloads within Keil V5.24 now starts the program in the target (an nRF51822) as desired.

Are the sources for the changes you made to V244 to work around the Keil issue available?
I would like to be able to build this image myself.

This firmware also seems to have solved another issue I had, which was that settings such as
auto_rst.cfg did not persist across a power cycle of the LPC11U35. i.e. you could set this mode and others, and the behavior changed appropriately, but cycling power would return to the default.
With the V244 version, the setting are now persistent.

Thanks,
Philip

@c1728p9
Copy link
Contributor

c1728p9 commented Nov 29, 2017

Hi @OSHChip-Owner I pushed my reset changes here (note - these are hacks):
https://github.com/c1728p9/DAPLink/tree/uvision_reset_test

As for the auto_rst.cfg persistence, this is because the lpc11u35 didn't have a flash driver in DAPLink. The recently released version 0244 has a flash driver for the lpc11u35 (added in #255), so if you try the most recent release settings will persist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants