EmbDev.net

Forum: ARM programming with GCC/GNU tools siprintf problem


Author: Thomas Fernando (thomas_f)
Posted on:

Rate this post
0 useful
not useful
Hello ,
I have a problem when I use "siprintf". The code snippet is below :
 while(1)
 {
   if((getElapsedSysTICs(startTimeRTC) > TEN_MS))
   {
      startTimeRTC += TEN_MS;
      ADC_Val=Init_Read_ADC();
      siprintf(buffer,"%u",ADC_Val);
      uart0Puts("\r\n");
      uart0Puts("hello");
   }
 }

The uart0Puts gives me junk characters when it enters the loop for the
first time.Also the micro gets reset occasionally. If I comment out the
siprintf , then I never face any problems.
If I put the value as greater than HALF_SEC,then too the problem does
not arise. Has anyone faced a problem like this ?

Thomas

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
All formatted I/O functions (printf, scanf, sprintf etc.) require at
least 4k bytes of stack. Is it possible that you have a stack overflow?
That would certainly fit the non-deterministic behaviour you have
described.

Clifford

Author: Thomas Fernando (thomas_f)
Posted on:

Rate this post
0 useful
not useful
Clifford Slocombe wrote:
> All formatted I/O functions (printf, scanf, sprintf etc.) require at
> least 4k bytes of stack. Is it possible that you have a stack overflow?
> That would certainly fit the non-deterministic behaviour you have
> described.
>
> Clifford

Hi Clifford,

// Stack Sizes
  .set  UND_STACK_SIZE, 0x00000004
  .set  ABT_STACK_SIZE, 0x00000004
  .set  FIQ_STACK_SIZE, 0x00000004
  .set  IRQ_STACK_SIZE, 0X00000080
  .set  SVC_STACK_SIZE, 0x00000004
is what my crt0.s says.I am looking for docs which could help me figure
out this cryptic stuff.
UND_STACK_SIZE should the user mode stack ,I think.But 0x00000004 sounds
like 4 bytes which is not meaningful.Any links which would be helpful to
read up on ?

BTW sprintf works just fine , but siprintf does not. Since siprintf is a
reduced sprintf I thought it would require less stack space.


Thomas

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
Thomas Fernando wrote:
> // Stack Sizes
>   .set  UND_STACK_SIZE, 0x00000004
>   .set  ABT_STACK_SIZE, 0x00000004
>   .set  FIQ_STACK_SIZE, 0x00000004
>   .set  IRQ_STACK_SIZE, 0X00000080
>   .set  SVC_STACK_SIZE, 0x00000004
> is what my crt0.s says.I am looking for docs which could help me figure
> out this cryptic stuff.
These are the stack sizes for a number of processor exception modes.
Neither are relevant since the mode your code will run in will
(normally) be USER mode.

> UND_STACK_SIZE should the user mode stack ,I think.But 0x00000004 sounds
> like 4 bytes which is not meaningful.Any links which would be helpful to
> read up on ?
No, that is the stack size for 'undefined' processor mode. The processor
should not normally get into this state.

It is likely that the USER stack is set programitically to a value
defined in the linker script rather than directly in crt0.s. The linker
script is likely to be called ldscript or some other name with a .ld
extension.



> BTW sprintf works just fine , but siprintf does not. Since siprintf is a
> reduced sprintf I thought it would require less stack space.
>
Since the result of a stack overflow is non-deterministic, that may be
more luck than judgement. It all depends on how the corrupted stack is
used and how it is corrupted, and these things can change significantly
with only minor (and usually unrelated) changes to the code.

Clifford

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
Sorry, you asked for links, this is pretty comprehensive:
http://www.state-machine.com/resources/papers.htm

As ever in programming there is more than one way of doing things, and
the approach described in this article may not match that taken in any
examples you are working from, although there will be broad
similarities. Also not all ARM microcontrollers are identical, often
having different boot methods, interrupt controllers, memory maps,
peripherals etc. This however (apart from perhaps memory mapping) does
not have much impact upon the runtime start up requirements.

Clifford

Author: Thomas Fernando (thomas_f)
Posted on:

Rate this post
0 useful
not useful
Thanks for that.

Clifford Slocombe wrote:
> Sorry, you asked for links, this is pretty comprehensive:
> http://www.state-machine.com/resources/papers.htm

Author: Thomas Fernando (thomas_f)
Posted on:

Rate this post
0 useful
not useful
Hi Clifford,

LPC2138-ROM.ld says
/*********************************************************************** 
/
/*  ROM.ld:  Linker Script File
*/
/*********************************************************************** 
/
ENTRY(_boot)
/* was 0x400 */
STACK_SIZE = 0x1000;

/* Memory Definitions */
MEMORY
{
  ROM (rx) : ORIGIN = 0x00000000, LENGTH = 512k
  RAM (rw) : ORIGIN = 0x40000000, LENGTH = 32k
}
etc. etc.

After making the change the siprintf works just fine.
To verify I put back the old value (0x400) and the problem was there.
I still had a problem after changing back to 0x1000.It got resolved
after I did "Make Clean" prior to "Make All".
Since there is 32k of RAM , why not make the stack size even larger ?
Are there any trade-offs to this ?

Thanks again
Thomas Fernando

Clifford Slocombe wrote:
> All formatted I/O functions (printf, scanf, sprintf etc.) require at
> least 4k bytes of stack. Is it possible that you have a stack overflow?
> That would certainly fit the non-deterministic behaviour you have
> described.
>
> Clifford

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
Thomas Fernando wrote:

> Since there is 32k of RAM , why not make the stack size even larger ?
> Are there any trade-offs to this ?
>
That depends on your application. The RAM is used for the user mode
stack, static data/objects, the heap, the exception mode stacks, and
possibly the interrupt/exception vector table or even code.

If your code and vector tables are located in Flash, and you are not
using dynamic memory allocation (which with only 32K it is
unlikely/unwise in any case) then you could indeed extend your stack.

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.