I've created a custom design with the AT91SAM9RL processor, but instead of using crystals, I've attached a 12 MHz oscillator signal to XIN and a 32.768 kHz oscillator signal to XIN32. Both oscillator signals have been level-shifted to 1.2V levels. The processor core is run at a 1.2V level as well. The BMS pin is set to BMS = 1.

The SDRAM bus is 32-bit, and is connected to two MT48LC16M16A2BG-75 SDRAM chips. I believe that this is very similar to the evaluation kit.

I can connect to the processor using the JTAG SAM-ICE running under Windows XP, but when starting SAM-BA, I receive the warning that "External RAM initialization failed." If I click on "Continue anyway", and enter the main SAM-BA program, I find that I can still start up SPI Dataflash. The SPI dataflash applet is able to load.

What might be going on here, and is it possible to modify SAM-BA so that external clocks are used?

In the \SAM-BA v2.10\applets\at91lib\boards\at91sam9rl-ek\board_lowlevel.c file, I've tried to modify the code so that the main oscillator is bypassed:

AT91C_BASE_PMC->PMC_MOR = BOARD_OSCOUNT | AT91C_CKGR_OSCBYPASS;

But this seems to have no effect.

If you think there is a clock issue, you could try confirming the clock applied to the SDRAM.

I'm not sure turning on/off the internal oscillator's inverter will make much difference since you don't have a crystal attached to it's output.

May be it's an SDRAM issue. You should check the clock, voltages and signals (3.3V) to the part you mentioned.

You should be able to download and run application and diagnostic code on the internal SRAM. For there you could do some validation of the SDRAM setup and performance. You should be able to use SAM-BA or Keil to run code on the board. Certainly with the SAM-ICE and Keil you could debug code in both the internal SRAM and external SDRAM.

Thank you very much for your reply, CptTitanic; this is greatly appreciated! I've checked voltages to the SDRAM parts, and these seem to be relatively normal (~3.3V).

The SDCK signal to the SDRAM is strange, however; after the SAM-BA code tries to set up SDRAM, the SDCK signal appears to idle high, with a few small dips indicating that something is happening. I do not see the signal drop to a low level.

Moreover, the SDCS-NCS1 chip select of the SDRAM drops low (and stays low) after the SDRAM initialization code runs at the beginning of SAM-BA start up.

I strongly suspect that this is a clock issue, but I could be wrong. I've tried physically pressing on the SDRAM parts (which are in BGA packages) to check for balls that are not connected, but this doesn't do anything.

The external clock signals applied to the part appear to be good.

I would like to run U-Boot and Linux on this PCB, but of course with SAM-ICE and Keil, it would be more than possible to write diagnostic code.

I now suspect that the problem might be the associated with not having set up pass-though for the slow clock (32.768 kHz). Since my custom board does not have an external slow clock crystal, I need to write code in SAM-BA to be able to bypass the slow clock. I believe that the slow clock is required for watchdog initialization.

In the \SAM-BA v2.10\applets\at91lib\boards\at91sam9rl-ek\board_lowlevel.c, I've attempted to modify the code so that the main oscillator and slow clock oscillator is bypassed as well:

AT91C_BASE_PMC->PMC_MOR = BOARD_OSCOUNT | 0x02;
AT91C_BASE_CKGR->CKGR_MOR = BOARD_OSCOUNT | 0x02;
AT91C_SYS_SLCKSEL = AT91C_SLCKSEL_OSC32BYP; // error here

However, with the following lines of code being changed, I receive the following compile error:

../../at91lib/boards/at91sam9rl-ek/board_lowlevel.c:116:2: error: lvalue require
d as left operand of assignment
make: *** [obj/sram_board_lowlevel.o] Error 1

What would I have to change in the code above to be able to bypass both the main clock and the external slow clock? Are the first two lines of code correct?

I also don't understand what is the difference between PMC_MOR and CKGR_MOR.

It's a pointer, right??
*AT91C_SYS_SLCKSEL |= AT91C_SLCKSEL_OSC32BYP; // Bypass
*AT91C_SYS_SLCKSEL &= ~AT91C_SLCKSEL_OSC32EN; // Disable XOUT?

or

AT91C_BASE_SYS->SYS_SLCKSEL |= AT91C_SLCKSEL_OSC32BYP;
AT91C_BASE_SYS->SYS_SLCKSEL &= ~AT91C_SLCKSEL_OSC32EN;

Do you need to make sure the internal is enabled? And running?
AT91C_SLCKSEL_RCEN;

Alternatively, if you want use your external source
*AT91C_SYS_SLCKSEL |= AT91C_SLCKSEL_OSCSEL;


https://dev.xdevs.com/projects/c3se/rep ... lck/slck.c

Thanks for *pointing me in the right direction, CptTitanic!

Once I correct the third line (so *AT91C_SYS_SLCKSEL is indeed a pointer), the following code compiles, but causes the SAM-ICE jtag to become non-responsive once SAM-BA loads:

AT91C_BASE_PMC->PMC_MOR = BOARD_OSCOUNT | 0x02;
AT91C_BASE_CKGR->CKGR_MOR = BOARD_OSCOUNT | 0x02;
*AT91C_SYS_SLCKSEL = AT91C_SLCKSEL_OSC32BYP;

I've tried to follow the suggestions that you've given (and thank you for the very informative link). I've now modified the above code to read:

AT91C_BASE_PMC->PMC_MOR = BOARD_OSCOUNT | 0x02;
AT91C_BASE_CKGR->CKGR_MOR = BOARD_OSCOUNT | 0x02;
AT91C_BASE_SYS->SYS_SLCKSEL |= AT91C_SLCKSEL_OSC32BYP;
AT91C_BASE_SYS->SYS_SLCKSEL &= ~AT91C_SLCKSEL_OSC32EN;
*AT91C_SYS_SLCKSEL |= AT91C_SLCKSEL_OSCSEL;

However, after loading the SDRAM applet, the SDRAM chip select remains low, and the external SDRAM memory fails the memory test. The SDRAM chip select is wired to SDCS-NCS1, and is high when power is initially applied to the custom circuit board. I do not see the SDCS-NCS1 toggling normally when the applet attempts to write test data into SDRAM.

Here is the debug trace code sent over the debug serial port:

-I- -- EXTRAM ISP Applet 2.10 --
-I- -- AT91SAM9RL64-EK
-I- -- Compiled: Mar 17 2011 13:08:38 --
-I- INIT command:
-I- Communication link type : 2
-I- Data bus width : 32 bits
-I- External RAM type : SDRAM
-I- Init SDRAM...
-I- NK: Applet fail.
-I- Init successful.
-I- End of applet (command : 0 --- status : f)

I inserted the "NK: Applet fail." text into the applet code to check and see where the fail is occurring. The fail occurs when the SDRAM memory cannot be checked.

Following the suggestion by CptTitanic, I've written source code to verify processor operation, and I've found that the problem does not appear to be the external clocks at all!

The line of code

AT91C_BASE_PMC->PMC_MOR = BOARD_OSCOUNT | AT91C_CKGR_OSCBYPASS;

seems to bypass the main clock, and by running a small test program from internal SRAM, I can write to the DBGU serial port at different baud settings. I also used an oscilloscope to check again that the clocks were working.

I then modified my small test program to write 32-bit numbers into SDRAM and read back the numbers. Unfortunately, I found that "D5" on the memory bus does not seem to respond. X-ray inspection of the PCB shows that "D5" is not completely soldered to the pad, so of course the SAMBA external memory test fails!

To compile the test code, I used makefiles provided in the AT91lib software library that can be found on the SAM9RL-EK homepage on the Atmel website. The makefiles were adapted from the "getting started" example given in the /packages/ directory.

GNU compilers were used; these were the Codesourcery Lite versions.

I also obtained a Windows binary package of OpenOCD from Freddie Chopin's website (http://www.freddiechopin.info), and I used an Amontec Jtagkey-tiny to upload code to the AT91SAM processor internal SRAM.

Thankfully, OpenOCD supports the AT91SAM9RL processor. I had to write a small configuration file, and then use telnet to send commands to OpenOCD.

In my openocd.cfg configuration file, I had the following two lines:

source [find interface/jtagkey-tiny.cfg]
source [find target/at91sam9rl.cfg]

I ran openocd by typing "openocd" in the same directory that I had created the openocd.cfg configuration file. The openocd binary had been added to my system $PATH variable.

I then opened another Terminal window and started telnet:

telnet localhost 4444

The telnet commands that I sent to OpenOCD were the following:

halt
load_image test-at91sam9rl-ek-at91sam9rl64-sram.bin 0x00300000
resume 0x00300000

The processor had to be stopped before loading the test program image. The resume operation started the program at the proper address.

I set this up in 32-bit Windows XP running in Virtual Box, but I am certain that this procedure would also work with Linux or even with Mac OS X. I found that OpenOCD and the JTAG drivers were more difficult to compile under Windows 7 (64-bit), so I abandoned this endeavor. Windows XP works just fine for running OpenOCD.

So thank you very much, CptTitanic, for your suggestion to write test code: I think this helped to lead me in the right direction.

Glad to hear you got resolution to your problem.

I'll note that it should be possible to load/run example applications in internal RAM, downloaded by SAM-BA. I was able to do this with the getting-started stuff on the 9260.

Yes, that is also a great comment. Thank you once again for your help!