I’ve been doing AT91SAM7S programming for a while now (over a year) using KEIL tools. I use KEIL’s ULINK tool to load code into my target or to debug it. FWIW, the stuff (i.e., crystal & cap’s, JTAG interface, RESET circuit, etc.) around the micro was directly copied from an ATMEL eval board.
Unfortunately, I’ve never had real reliable downloading of code into my target. It usually works, but not always. When it doesn’t work, I go through the same sort of steps over and over, like cycling power on the target, the ULINK, cycling the hardware reset, restarting the IDE, etc., and eventually the code downloads and runs just fine. Anyone know of why that might be? In other words, why the downloading of the code is not [more] reliable?
A second problem I’ve got is associated with an ASSERT feature I built into the project that attempts to reset the board via the on-board reset controller. Through software, you can issue a reset command to the micro. The problem is that when I do this, sometimes it works, sometimes it doesn’t. When it doesn’t work the micro appears to be stuck in reset. The same sort of steps I do above to get the code to download get the board un-stuck, eventually. I replaced the code that issues a reset via the on-chip reset controller with a call to the reset vector, like this: ((void(*)(void))0x100000)(); and that made my ASSERT feature work rock solid. Has anyone else had problems with issuing a reset via the RSTC on the AT91SAM7S parts, and if so, were you able to get around the problem?
I’m beginning to think that these two problems may be related, and sure would appreciate some help in fixing them.
Hmmm… I tried the code on a similarly configured ATMEL eval board and guess what…? The code runs just fine. So, I found another (different design) SAM7S256 based board and guess what…? The code runs just fine on that board too. Something tells me I’ve probably got a hardware problem after all. I guess that’s good news.
After much hardware investigation, the only difference I could find between AT91SAM7S256 boards that worked and those that didn’t was the date code of the microcontroller.
I found that if I put different date code chips on my boards (that weren’t working reliably) they started working just fine. Unfortunately, the date codes for the parts that work (0604) are earlier than the ones that don’t work (0621). That’s not good.
0604 = 4th week of 2006
0621 = 21st week of 2006
My local ATMEL FAE and distributor are bringing me a few different date code parts for me to try to see what happens. Hopefully some of them will be fairly current.
Okay… tech support from ATMEL in Rousset found a problem in the startup assembly code automatically generated by KEIL’s configuration wizard. Here’s their response (which after I implemented seems to have fixed this problem).
Here is an extract from the datasheet (PMC section):
If a new value for CSS field corresponds to PLL Clock,
– Program the PRES field in the PMC_MCKR register. – Wait for the MCKRDY bit to be set in the PMC_SR register. – Program the CSS field in the PMC_MCKR register. – Wait for the MCKRDY bit to be set in the PMC_SR register.
However, they do not program correctly the PMC. They have programmed the MCKR in one time and they have forgotten to wait the MCKRDY flag which is mandatory to be sure they system clock has correctly switched on…
So, it should be more:
PMC_MCKR_Val1 EQU 0x00000004
PMC_MCKR_Val2 EQU 0x00000007
PMC_MCKRDY EQU (1<<3) ; MCK Ready Status
; Program 1st PRES field
LDR R1, =PMC_MCKR_Val1
STR R1, [R0, #PMC_MCKR]
; Wait until MCK is stabilized
MCK_Loop1 LDR R2, [R0, #PMC_SR]
ANDS R2, R2, #PMC_MCKRDY
BEQ MCK_Loop1
; Then program CSS field
LDR R1, =PMC_MCKR_Val2
STR R1, [R0, #PMC_MCKR]
; Wait until MCK is stabilized
MCK_Loop2 LDR R2, [R0, #PMC_SR]
ANDS R2, R2, #PMC_MCKRDY
BEQ MCK_Loop2