I’ve written allot of C/C++ for the PC, but never worked with a embedded device before.
I’ve followed the directions in the “Using Open Source Tools - Guide by Jim Lynch” and it compileds a 2Meg file that I can’t copy to the device, as it’s to large.
I’ve also downloaded about 15 other examples of blinking the LED’s, no luck. I can get them to compile (with some work) and copied to the board, but no blink. Some make a high pitch sound but no blinking LED’s.
The only thing that works is the sparkfun already compiled .BIN file. (there code doesn’t come with a makefile. When create a makefile and compile it it doesn’t work)
My question is:
Has anyone out there gotten a blink LED demo to work on a SAM7-256 rev E board, with YAGARTO tool chain? (maybe a difference between Rev D and E is the problem?)
I’m starting to think there is something wrong with the code that is compiled?
I guess I would like to know that it is possible to get thing to work with the tools I’m using, I’m really starting to wonder.
What is your application size, as reported by the arm-elf-size or arn-none-eabi-size tools? This is standard GNU toolchain stuff here. If the size specified under “text” is very high, then give us an objdump or map file. If its a fairly small number (several thousand) then its likely a linker start address issue.
What is your Makefile? What is your linker script (.ld file)? What is your source file? Paste them to codepad.org for readbility.
When using other example applications, are you sure they are toggling to correct IO pin? Have you modified them to work otherwise?
I created around 15 different projects all to blink the LED’s.
I gave up on the one that compiles to 2Megs.
The code I’ve been working with compiles to about 1K.
I’m wondering if it’s a hardware issue in terms of something changing between REV’s of the hardware. As some code came as eclispe projects, that compiled without my intervention, and did not blink the LED’s after copied to the board, I’ve been wondering if it’s not a issue with LED IO postions? Memory locations… something low level hardware related. Or something else that is different between my hardware and the examples…
I have no .ld file. I think the .cmd file and .s tell the linker what to do. (or where to go)
Here is a link to the project I like the most, as it’s the smallest.
I tried Yagarto and Jim Lynch tutorials and just couldn’t make it work. I gave up and went with Crossworks. It’s just clean and easy to use, so I bought the personal license.
I can’t really figure out your link and I just have the SAM7-H256 header board, but here’s a simple Blink LED program that should compile under GCC. Far simpler than the Jim Lynch tutorial code, which is meant to touch other concepts rather than just simple I/O. You need to make sure it’s toggling the correct IO on your devel board and that the LEDs are enabled. I haven’t looked at the P256 yet, but most devel boards have jumpers to enable/disable functions on the board.
I’m sure the code is pretty bad. I just cut and pasted it out of old test code I made a long time ago. It toggles the LED at one speed, and if you ground the INPUT_PIN it will blink at a different speed. So the code has simple input and output. Change the defines to use the correct IO pins on your board.
#include "AT91SAM7S256.h"
#define nop() __asm__ __volatile__("nop")
#define LED (1<<0) // PA0
#define INPUT_PIN (1<<1) // PA1
#define INT_PIN (1<<2) // PA2
static void initialize( void);
void delay_us( int time);
void delay_ms( int time);
int main(void)
{
int delay = 100;
volatile long input;
initialize();
volatile AT91PS_PIO pPIOA = AT91C_BASE_PIOA;
while(1)
{
input = pPIOA->PIO_PDSR; //for debugging. Watch input variable to check if inputs working.
if(( pPIOA->PIO_PDSR & INPUT_PIN) == INPUT_PIN)
delay = 1000;
else
delay = 100;
pPIOA->PIO_CODR = LED;
delay_ms(delay);
pPIOA->PIO_SODR = LED;
delay_ms(delay);
}
}
static void initialize(void)
{
//Turn on the peripheral clock. Without this on, inputs do not actually register in the PDSR register
volatile AT91PS_PMC pPMC = AT91C_BASE_PMC; // pointer to PMC data structure
pPMC->PMC_PCER = (1<<AT91C_ID_PIOA); // enable Timer0 peripheral clock
volatile AT91PS_PIO pPIOA = AT91C_BASE_PIOA;
pPIOA->PIO_PER = (LED | INPUT_PIN); // Set PIO to control LED and button.
// Initialize Input
pPIOA->PIO_ODR = INPUT_PIN ; // Disable outputs for INPUT pins. (not needed as all pins default input on reset)
pPIOA->PIO_PPUER = INPUT_PIN; //Pullup Enable (not needed as all pullups are enabled on reset)
// Initialize Output
pPIOA->PIO_OER = LED; // Enable output for LED.
pPIOA->PIO_SODR = LED; // Turn LED off.
pPIOA->PIO_PPUDR = LED; //Pullup disable
}
void delay_us(int delay)
{
while(delay--)
{
__asm volatile (" NOP");
__asm volatile (" NOP");
__asm volatile (" NOP");
__asm volatile (" NOP");
__asm volatile (" NOP");
__asm volatile (" NOP");
__asm volatile (" NOP");
__asm volatile (" NOP");
__asm volatile (" NOP");
__asm volatile (" NOP");
__asm volatile (" NOP");
__asm volatile (" NOP");
__asm volatile (" NOP");
}
}
void delay_ms(int delay)
{
char i;
while(delay--)
{
for(i=0; i<4; i++)
{
delay_us(250);
}
}
}
The SEGGER JLink does come with a set of flash loaders which permits you to download your application directly into the flash memory of your target system. These flashloaders include support for the Atmel AT91SAM7S256. The J-Link flashloaders are highly optimized for fast flash programming. These flashloaders, referred to as the Flash Download feature in the SEGGER documentation, is free of charge and included in the latest J-Link Software release (http://www.segger.com/cms/jlink-software.html). You can learn more about the Flash Download module at: http://www.segger.com/cms/j-link-arm-fl … nload.html. Currently the Flash Download module is directly supported by the following debuggers/development environments:
GNU Debugger (GDB) + J-Link GDB Server
IAR Embedded Workbench for ARM
Keil RealView MDK
RDI compliant debugger + J-Link RDI
Yagarto GNU ARM Toolchain (Free) + J-Link GDB Server
But in general, the Flash Download feature can be used with any environment which supports the J-Link. Even if it is not possible to select your target device in the debugger, you can always select it in the J-Link control panel which is opened when a debug session starts.
There is also a much reduced cost J-Link EDU http://www.segger-us.com/jlinkedu.htm designed specifically for educational and non-commercial use which includes the SEGGER Flash Download module, SEGGER’s GDB Server and the SEGGER Flash Breakpoint module enabling the use of unlimited breakpoints while debugging in Flash (removes the hardware breakpoint limit).
Such a frustrating little board.