Hi,

I'm working with the SAM3U for some time now, using the gcc toolchain, with modified makefile and linker script.

This works quite well, but every now and then after flashing, the SAM3U seems to be in Nirvana, not doing anything, not even starting the low-level init (including starting the external 12MHz quartz). Then I put a "LED on" line somewhere in the startup code, and then it suddenly works again.
Very strange behaviour that I don't understand at all.
For flashing the device I use either OpenOCD with an Olimex ARM-USB-TINY-H or the Samba application. Both show the same results.

I'm running FreeRTOS and FatFs on the chip, well, if it runs, so I need lots of the SAM3U4's sram.
Maybe there's something in the Makefile or linker script going wrong? Please have a look at the attached files.

Thanks,
IBE

Hello IBE,

Could you please post the startup code? Do you use the SAM3U evaluation board ?

Best regards,
Joerg

Hi Joerg,

see attached startup code, which is almost like the original from Atmel.
I changed the start of stack pointer to end of SRAM1, and it might be better since then.

Another issue:
How do I actually make use of SRAM1? I've got the feeling that I'm limiting myself with this modified linker script...

Thanks,
IBE

edit: I forgot to mention, same behaviour on our custom made eval board as on SAM3U-EVK from Atmel.

What is the value of DEFAULT_PLLR in your lowlevel? If you set your speed to 96MHz you should set your waitstates to 3 at the start of Lowlevelinit.

Is your OSCOUNT value high enough for the crystal your using?

Do you use AT91C_CKGR_STMODE_2 for startup (normal as opposed to fast)

Is the AT91_CKGR_SRC bit set?

To use sram as one contigious block the datasheet says "The user can see the SRAM as contiguous at 0x20078000-0x20083FFF" thus, define a section starting at 0x20078000 of size 0xC000 and use that.

The memory you reserved at 0x20000000 - 0x20000100 is also only usefull if you actually move your vector table to sram in your ResetException function. Otherwise, you're wasting 0x100 of memory. (Not sure if FreeRTOS moves the vectors there though...)

Thanks for your response!


Some of these bits do not exist in SAM3U.
Anyway, the PLL is not the problem, as I don't use it at startup, only later on when USB is connected, and that works (then running on 48MHz).


Wow, thanks a lot, THAT helps.
So I define the sram as a whole, and keep
the stack pointer at the end of it, that seems to work.
I always find it very embarrassing if it's so easy to find in the datasheet...


I think that's done in the linker script, line 40:
_vect_start = ...;


The more I play with it, the more I think it's FreeRTOS configTOTAL_HEAP_SIZE. If that's too small I don't get an error message, and strangely the application starts after flashing, but not after another power down and up.

Thanks again for your help!

Hello IBE,

If you plan to use slow clock for low power mode you should keep in mind to change the flash wait state to a value other than 2.

See datasheet "SAM3U Errata: 46.2.1.1: Flash: Issue Running at Frequency Lower than 2.5 MHz" or http://www.at91.com/forum/viewtopic.php/f,24/t,19600/.


Regarding SRAM I use the following linker script:




Best regards,
Joerg

Hi Joerg,

that's how I changed just changed my linker script after incognito pointed me to the datasheet entry!
But good to know that it works somewhere else too!

At least I found that slow clock entry on my own, but I don't need it anyway. I always run on 12MHz or 48MHz.

Thanks,
IBE