[ECOS] printf does not work in user mode on Arm E7T

Thomas BINDER Thomas.Binder@frequentis.com
Wed Mar 26 11:59:00 GMT 2003


Hi!

My guess is that you have thread safety (option CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS) enabled, in which case printf, sprintf, fprintf use a Cyg_Mutex object for synchronization (via Cyg_StdioStream, c.f. http://sources.redhat.com/ml/ecos-discuss/2003-03/msg00194.html).  Have you set up your MMU such that access to kernel objects is not allowed in user mode?

best regards,
Tom


Andrew Lunn wrote:
> 
> This is not an area of eCos i know, so this is more of a guess.
> 
> How is your MMU setup? Maybe in user mode the MMU is stopping access
> to the memory where the serial port is, or some other critical region
> of memory. What is it trying to do when you get a BUS error? That may
> give you a clue.
> 
>      Andrew
> 
> On Wed, Mar 26, 2003 at 09:19:51AM +0100, Pierre Habraken wrote:
> > Hello,
> >
> > For demonstration purpose, I have inserted printf calls in a program
> > running on an Arm Evaluator 7T (controlled by gdb as a remote target).
> > The program is linked against newlib libc but and it uses redboot
> > syscalls (redboot.specs).
> > Some parts of the program runs in svc mode (cpsr = 0x13), other parts
> > run in usr mode (cpsr = 0x10), each mode using its own stack.
> > When printf is called with the processor being in svc mode, the
> > corresponding output is displayed in the gdb console and the program
> > continues then with its execution.
> > When printf is called with the processor being in usr mode, nothing is
> > displayed in the gdb console and the program hangs or raises a BUS
> > ERROR.
> > Could someone explain me what printf would not work in user mode ?
> >
> > Thanks in advance for any help.
> >
> > Pierre
> > --
> > ________________________________________________________________________

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss



More information about the Ecos-discuss mailing list