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
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
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
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
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
Thanks for that. Clifford Slocombe wrote: > Sorry, you asked for links, this is pretty comprehensive: > http://www.state-machine.com/resources/papers.htm
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
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.
Watch this topic
Disable multi-page viewPlease 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
Log in with Google account
No account? Register here.