| commit | 77c7abe4e7569ca8bb23dad6110c7209c8c55558 | |
| author | Dan Stahlke <dan@stahlke.org> | |
| Mon, 5 Dec 2022 02:12:16 +0000 (4 18:12 -0800) | ||
| committer | Antonio Borneo <borneo.antonio@gmail.com> | |
| Sat, 17 Dec 2022 09:33:40 +0000 (17 09:33 +0000) | ||
| tree | 85ccf65c5715f1bffb8ca5a75f321a468a398ce1 | treesnapshot (tar.gz zip) |
| parent | 0a829efda5c254ceca2371edb38e9b0e4a998706 | commitdiff |
at91samd: wait for nvm ready
Flashing a SAMD21J17D was failing during NVM erase. The samd21
datasheet specifies that one cause of error conditions is executing an
NVM command while the previous command is still running. The solution
is to wait for INTFLAG.READY after a command is issued.
SAMD21J17A was not exhibiting this problem. Perhaps the later silicon
revision has slower NVM erase times.
Signed-off-by: Dan Stahlke <dan@stahlke.org>
Change-Id: I19745dae4d3fc6e3a7611dcac628e067cb41e0f0
Reviewed-on: https://review.openocd.org/c/openocd/+/7391
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Flashing a SAMD21J17D was failing during NVM erase. The samd21
datasheet specifies that one cause of error conditions is executing an
NVM command while the previous command is still running. The solution
is to wait for INTFLAG.READY after a command is issued.
SAMD21J17A was not exhibiting this problem. Perhaps the later silicon
revision has slower NVM erase times.
Signed-off-by: Dan Stahlke <dan@stahlke.org>
Change-Id: I19745dae4d3fc6e3a7611dcac628e067cb41e0f0
Reviewed-on: https://review.openocd.org/c/openocd/+/7391
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
| src/flash/nor/at91samd.c | diffblobblamehistory |