The formatted I/O routines require a significant ammount of stack, at
least 4Kbyte in my experience. Check your stack allocation, and perhaps
increase it.

If that is not the problem then without knowing their definition, I
would suggest that the RTC macros or the lcd_print() function would be
the next things to suspect.

Clifford

Clifford ,

Thanks for your reply.I had sorted out the problem.It was with the
initialization routine for the RTC.
The LPC gives erratic problems when initialised improperly. For eg.
VICIntSelect &= ~VIC_BIT(VIC_EINT0);  // EINT0 selected as IRQ
//VICIntEnable = VIC_BIT(VIC_EINT0);  // EINT0 interrupt enabled
VICVectCntl1 = VIC_ENABLE | VIC_EINT0;
VICVectAddr1 = (uint32_t)DTMF_ISR;    // vector address of the ISR
VICIntEnable = VIC_BIT(VIC_EINT0);    // EINT0 interrupt enabled after
setting ISR function
When it was coded in reverse order i.e. interrupt enabled before setting
the address of the ISR ,the micro used to hang in this init routine.

However in the UART examples routines :
VICIntEnable = VIC_BIT(VIC_UART1);    // UART1 interrupt enabled
VICVectCntl6 = VIC_ENABLE | VIC_UART1;
VICVectAddr6 = (uint32_t)uart1ISR;    // address of the ISR
The reverse order "SEEMS" to work just fine.


Thomas

When it was coded in reverse order i.e. interrupt enabled before setting
the address of the ISR ,the micro used to "occasionally" hang in this
init routine.

Thomas

Sometimes you cannot avoid the "kinda~sorta" phraseology.

I find it hard to see how your 'solution' relates to your original
problem statement, but would suggest that after an incorrect
initialisation, all best are off for system behaviour, and you were
merely describing symptomatic behaviour rather than the root problem.

If you enable an interrupt before hooking the vector, and the interrupt
occurs (or is already pending), what gets executed may be undefined.
Typically however the runtime start-up would assign unused interrupts to
a dummy handler.

Even if it is defined (as a dummy handler for example), if the interrupt
occurs while the vector is being changed (because it is a non-atomic
assignment) then the address will be inconsistent and what executes is
undefined but certainly wrong.

UART interrupts only occur when a character is received or transmitted,
whereas time passes regardless, so that might explain why there is no
interrupt pending for the UART, but there is for the RTC.

Typically a UART interrupt has two enabling levels, in the device (for
Tx, Rx, overrun, parity error, etc), and one in the interrupt
controller. So it may be that the problem does not occur because no
device level interrupt is enabled before the vector is assigned.

Nonetheless, I suggest that the appropriate set-up sequence for any
interrupt hook is:

Disable interrupt in interrupt controller
Disable interrupt in the device
Clear any pending interrupt in the device
Clear any pending interrupt in the interrupt controller
Hook the interrupt vector
Enable interrupt in the device
Enable interrupt in the interrupt controller

The above is general advice, not specific to any particular peripheral
or micro-controller (or even ARM). Adapt it as necessary.


Clifford

Clifford,

Clifford Slocombe wrote:
> I find it hard to see how your 'solution' relates to your original
> problem statement, but would suggest that after an incorrect
> initialisation, all "best" are off for system behaviour, and you were
> merely describing symptomatic behaviour rather than the root problem.

Yes,it does look like that. I "assumed" it was a compiler/stack problem.

Thanks
Thomas