EmbDev.net

Forum: ARM programming with GCC/GNU tools jump to another


von Roman M. (romez777)


Attached files:

Rate this post
useful
not useful
Hello.

MCU - at91sam7s64
toolchain - Yagarto

I have two distinct applications residing in the internal flash. The
first one located at 0x100000, prints string and transfers control to
the second application located at 0x104000, which lights the LED and
prints string.

I have taken C-startup from at91sam7s_example_gamma_20070830" example
from Martin Thomas' website. So, what I basically did:

1)the 1st application is compiled with vectors placed in ROM
2)in the 2nd application vectors are placed in RAM. It also does
remapping.
3)2nd application configures timer and timer's interrupt handler,
where LED blinking occurs and where I also print a string out DBGU.

Before transferring control, I also disable all interrupts in the first
application:

AT91C_BASE_AIC->AIC_IDCR = ~0;
AT91C_BASE_AIC->AIC_ICCR = ~0;

for (i = 0; i < 8; ++i) {
       AT91C_BASE_AIC->AIC_EOICR = 0;
}

The 2nd code, upon receiving control, enables IRQ and FIQ.

The whole thing doesn't work as I expected. First application prints,
then runs second application, which lights LED on but instead of
printing string it outputs some garbage on a DBGU port.

The interesting thing is that that string from timer service routine
is ALWAYS printed properly, while the first AT91F_DBGU_Printk() is
clumsy. May be after enabling interrupts and before issuing the first
'printk' some timeout should pass or whatsover?

I wonder is there any special peripheral reset procedure that I need to
do before passing control to another application?

PS. I attached the screenshot, so that it'd easier to understand what's
going on.

von Clifford S. (clifford)


Rate this post
useful
not useful
Roman Mashak wrote:
>
> PS. I attached the screenshot, so that it'd easier to understand what's
> going on.

I'd say that it is impossible to tell what is happening without seeing
the code, but it looks like there is always junk after printing
"Bootloader running..."; are you sure that string is correctly nul
terminated?

von Roman M. (romez777)


Attached files:

Rate this post
useful
not useful
Clifford Slocombe wrote:
> I'd say that it is impossible to tell what is happening without seeing
I'm attaching archive.

> the code, but it looks like there is always junk after printing
> "Bootloader running...";
When it runs standalone i.e. not passing control to another code, no
junk symbols appear and I may append as many extra strings as I want.

> are you sure that string is correctly nul
> terminated?
Yes. Assembly code says string is terminated with '\0'.

I am developing a hunch that this issue deals with a linker. As I
understand strings are usually placed in a .rodata section (speaking
about GNU toolchains). In my linker script, .rodata is included in .text

So may be after second image does remapping, this part of section
somewhow becomes unavailable and as a result, printing function takes
its argument from a random spot. Just a guess though...

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.