-
Notifications
You must be signed in to change notification settings - Fork 477
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
partial support for SAML11D16A #1469
base: develop
Are you sure you want to change the base?
Conversation
This pull request introduces 14 alerts when merging a69beeb into 72299f5 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging 0cad408 into 72299f5 - view on LGTM.com new alerts:
|
Thanks for the addition! Regarding the assert-reset-with-clock-low API: On my feature/debug_sequences branch, there is a new debug probe API that provides full pin control (required for the Fwiw, the SAML11 CMSIS-Pack does provide debug sequences for handling the security states and special flash programming requirements. In fact, the standard flash programming sequences were added specifically to support the SAML11. However, pyocd won't support the flash programming sequences in the first release of debug sequence support, so this PR will still be required. |
I had a feeling the upcoming debug_sequences feature would allow support for debugging a wider range of MCUs, but I had an immediate need due to development of a client board so I went ahead and added the necessary code. I haven't looked at the flash sequences support in the new branch yet but I'd like to note that the flash binary included in the CMSIS-Pack has different function entry point names, and the python conversion script included in pyocd was unable to find the required flash routines. The flash binary in this pull request is actually newly written. |
Thanks! I'll merge #1478 once you say it's acceptable (or within a week or two). I think it'll be fine, but it'd be nice to have another set of eyes. |
partial support for Microchip/Atmel SAML11D16A
SAML11 devices contain security features that block debugger access according to level (DAL).
To reset DAL level a mass erase command (CE2) must be issued with the correct key.
Upon reset the internal secure boot code runs before the cpu reaches the reset vector. I assume that
is why the jump to reset vector is not caught by the debugger. A breakpoint is set to halt the CPU.
I am using a custom board with cmsis-dap (v1) based debugger.
SAML11 datasheet reference