The old supervisor mode chestnut...

nobody wrote on Monday, January 29, 2007:

Hello peeps,

I have myself an at91sam7x256-ek IAR kickstart dev kit, including the IAR branded j-link.
I’ve downloaded pretty much everything related to GNU ARM development i can find, so i have all the tools, and i can just about get them to work (though it did take me a week to discover that you had to d/l the .bin via sam-ba before you could use the GDB stuff!). My set up is eclipse with the cdt and embedded debugger, using the GNUARM toolchain, and while i have the 30-day licence, the segger jlink gdb server, as it works better then the yahoo groups version.

Anywho, i’ve been trying to get the lwIP_Demo_Rowley_ARM7 to work, but it’s failing on the portRESTORE_CONTEXT() macro.
Now i’ve searched, and it seems to be a common problem, but i have seen any ‘this is how to fix it’ posts apart from make sure it’s in supervisor mode. Well, as far as i can tell it is. I’m using the demo pretty much right out of the box, i’ve just move a couple of directories around, and edited the makefile accordingly.

So what is it i’m doing wrong?


Paul (nobody) Sheppard

nobody wrote on Monday, January 29, 2007:

In portRESTORE_CONTEXT(), when you execute the line

LDMFD    LR, {R0-R14}^

the ***user/system mode*** registers should get loaded with values such that R1 contains 0x01010101, R2 contains 0x02020202, up to R14 which should contain 0xaaaaaaaa.

If executing this line causes any of the Supervisor mode registers to change then you are not in the right mode.  Especially, if the Supervisor mode LR contains 0xaaaaaaaa after the execution of the above line then its a dead give away.

I presume you are using the start up code form the demo?

Inspecting the mode bits of the CPSR should show that the last last 5 bits are set to 10011 binary.

If you are in the right mode then can you say which line within portRESTORE_CONTEXT causes the problem?

nobody wrote on Monday, January 29, 2007:

Wow, quick reply cheers.

at the point restore_context is executed the cpsr is 0b11110111, and R1-14 are alsorts of values, so not at all correct.
My mind doesn’t work too well in asm, but the last access to that register in boot.s look to be setting SVR mode…

Paul Sheppard

nobody wrote on Monday, January 29, 2007:

sorry, my mistake, it’s 0xF3. So the last 5 bit are right… just stepping through now.

nobody wrote on Monday, January 29, 2007:

Bombs out on:
    /* Restore all system mode registers for the task. */               
    "LDMFD    LR, {R0-R14}^                                        \n\t"    \

where cpsr is 0xd3, and error returned: Cannot access memory at address 0x1111110d

nobody wrote on Monday, January 29, 2007:

Weird - LR must be 0x1111110d I think.  Looks like this is the value that should be in R11.  Thoughts anybody?

You mentioned that you changed the makefile.  Was this just the paths?

nobody wrote on Tuesday, January 30, 2007:

yep, just the paths. I moved the code to my project directory and moved the includes and sources referenced there too.

I’ll go ahead try the demo where it unpacks to and not alter anything…

nobody wrote on Tuesday, January 30, 2007:

Ok, the fresh demo does the same compiled under GCC, but compiling under Rowley Crossworks and using the same tools (eclipse, arm-elf-gdb, jlinkgdb, etc) for debugging works just fine. Devils in the detail, somewhere.

nobody wrote on Tuesday, January 30, 2007:

Which version of and GNUARM are you using?

nobody wrote on Tuesday, January 30, 2007:

All the lastest:
FreeRTOS v4.1.3
GNUARM v4.1.1 (cygwin binary)

i guess something’s wrong with the boot.s/atmel-rom.ld

nobody wrote on Tuesday, January 30, 2007:

Just tried FreeRTOS v4.1.0, and GNUARM v4.1.0

Still no go :frowning:

nobody wrote on Thursday, February 01, 2007:

update: i used Winarm and info from here:
to compile and run the project which got past the portRESTORE() bit, but then locked up somewhere in the yeild section (both co-op and pre-emp).
even tried using the startup script, liner script and makefile of a similar project to no avail - locked up as above.

I simply don’t have the experience or knowledge of the ARM arch. or the AT91SAM7 to be able to fiddle with the assembly start-up scripts (where surely the problem lies). To that end I’m giving up and using rowley - it worked first time!