We have noticed that our DA14585-based device will occasionally stop advertising. We have tried running the application on the debugger but it has not shown the issue with this configuration, so we are trying to hot plug the debug adapter after the device has stopped advertising. I have the CFG_DEVELOPMENT_DEBUG defined in da1458x_config_basic.h and I have followed the instructions located here:
http://www.keil.com/support/docs/3697.htm
However, the device still ends up at the reset vector after attach, and still appears to be reloading the image at attach. How do we execute a hot plug of the adapter without resetting the device?
Device:
Hi mkelwood,
Could you please clarify how you hot attach the debugger? From Keil or from JLink Commander? If you hot attach the debugger from Keil, the sysram_case23.ini script will be executed, the device will reset and the image will be loaded again.
Thanks, PM_Dialog
Thank you PM_Dialog. I am using the Keil uVision IDE for debugger attachment. I substituted an empty .ini as the initialization file and was able to hot attach the debugger. This appears to allow assembly-level debug only; there is no source-level debug function. But I can still set breakpoints in the disassembly window, view memory, examine state, etc so this is still quite useful.
有趣的是,是否成似乎并不重要r the CFG_DEVELOPMENT_DEBUG is defined or not; the hot attach function appears to work the same in both cases.
Thank you for your help!
Hi mkelwood,
Could you please clarify what do you mean with the empty .ini file? You are not using the sysram_case23.ini script? If the CFG_DEVELOPMENT_DEBUG is undefined should not be able to attach the debugger. This definition either enables or disable the debugger. Are you able to hot attach the debugger without resetting the board?
Thanks, PM_Dialog
Hi PM_Dialog,
I basically used sysram_case23.ini with all the commands commented out - see attached. Using this as the initialization file (and clearing the settings as noted in the link I included in the original post) I am able to hot attach the debugger to a running system, regardless of whether CFG_DEVELOPMENT_DEBUG is defined or not. The system does not reset, but I am only able to do assembly-level debugging (it appears that no symbol information is available, which is strange).
With CFG_DEVELOPMENT_DEBUG undefined, I hot attach and I can see from the Program Counter and the map file that I am executing inside of main (not at the reset vector). The contents of SYS_STAT_REG are 0xE5, indicating that PD_DEBUG is functional. From here I can single-step the assembly, set breakpoints in the assembly etc.
With best regards,
MKE
Hi mkelwood,
With the procedure that you have followed, you will not able to attach the source code, so it is expectable that you are able only to do assembly-level debugging. Please try to do the following procedure. I tried it into theble_app_bareboneexample of the SDK. In the SDK directory of you project, please make 2 copies of your project. So, you should have yourinitial project, oneATTACHcopy and oneSIMULcopy of your project. Please check theSDK_folderscreenshot into the attachments. The original project will be used in order to download you firmware into the DA14580, without doing any modification in the debugging tab, just to download your binary image. TheATTACHcopy, will be used to attach the debugger without resetting you board, so please check thedebug_ATTACH_1/2screenshots from the attachments in order to do the same modifications. You should remove thesysram_case23.inifile and unclick the reset option after connection. TheSIMULcopy will be used for the simulation, and you will be able to find where the source code stops without doing a reset. Please check thedebug_SIMULimage, in order to do the proper configurations into this project. After the configurations that I described you should run in debug mode the ATTACH and SIMUL. Please check the follow example. In theATTACHimage, you will see that the code stops into the0x07FC088Aaddress, so if you copy-paste this address intoPC of the SIMUL project, you will see the source code that the firmware stops. Please try to do this procedure, and let me know if is working. Be aware that I tested in my side and it is working. There are not any configurations needed in the sysram_case23.ini file, so use it as it is. Please let me know if you have any follow up questions or issues.
Thanks, PM_Dialog
Hello PM_Dialog,
这个方法使用项目仅仅是一起ly as an aid in translating the assembly-level view from the ATTACH project into a source-level view? That is, breakpoints/steps/data view will still need to be done at the assembly level in ATTACH, but the SIMUL workspace assists in relating the code addresses, data addresses etc. to the source code?
Of course this can also be done with a MAP file and the LST file, but I can see the utility of using SIMUL to facilitate this process.
I will try it out and let you know.
MKE
minor-latin;mso-bidi-theme-font:minor-latin;background:white;mso-ansi-language:
EN-US">Himkelwood,
minor-latin;mso-bidi-theme-font:minor-latin;border:none windowtext 1.0pt;
mso-border-alt:none windowtext 0cm;padding:0cm;background:white;mso-ansi-language:
EN-US">Yes, exactly, the SIMUL project merely as an aid in translating the assembly-level view from the ATTACH project into a source-level view. Please try it and let me know.
minor-latin;mso-bidi-theme-font:minor-latin;border:none windowtext 1.0pt;
mso-border-alt:none windowtext 0cm;padding:0cm;background:white;mso-ansi-language:
EN-US">Thanks, PM_Dialog mso-ascii-theme-font:minor-latin;mso-hansi-theme-font:minor-latin;mso-bidi-theme-font:
minor-latin;background:white;mso-ansi-language:EN-US">