Passing data from boot-loader to application via RAM

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
pmlogo
New User
Posts: 2
Joined: Tue Jul 04, 2017 11:47 pm

Passing data from boot-loader to application via RAM

Post by pmlogo »

Hi All,

I am trying to pass some information from the boot-loader to the main application. Specifically, I want to tell the main application which image in flash is the one that actually booted.

I found that I can do this by having the boot-loader write some data into to the word at the very top of RAM (0x7FFFC), which is read later by the application. This works nicely. I've proven to myself that this word is never touched by the system (the contents survive intact across a full reboot).

I would have expected this location to be top of the stack. However, it seems that the top of the stack is actually at 0x7FF78 (confirmed by looking at the stack frames in xgdb, and also by the contents of the 'initial_sp' symbol in the .xe file).

So my questions are:

1. Does anyone have any idea why the top of the stack would be at 0x7FF78, and not 0x7FFFC?
2. Is it safe to use this area above the stack for our own data?
3. Is there any safer way to pass some data from the boot-loader to the application?

Paul


robertxmos
XCore Addict
Posts: 169
Joined: Fri Oct 23, 2015 10:23 am

Post by robertxmos »

Hi Paul,

The default C runtime leaves room at the top for use by the debugger and command line options passed into main() - useful for running tests under xsim.
The command line buffer length is set using:
-fcmdline-buffer-bytes=<value>
If set, the system will attempt to read the command line from the host.
If there is no host, argc=0
If the host requires a longer buffer, the system will trap.
(The xs2a also makes sure the stack is 64bit aligned)

I haven't tried it but if you need more space you could use the flag -fcmdline-buffer-bytes.

robert

initial_sp:
#if defined(__XS2A__)
// Ensure the sp address is 64-bit aligned.
.word .ram_base + .ram_size - 4 * ((1 + DEBUG_STACK_WORDS + _cmdline_buffer_stackwords) $A 2)
#else
.word .ram_base + .ram_size - 4 * (1 + DEBUG_STACK_WORDS + _cmdline_buffer_stackwords)
#endif
pmlogo
New User
Posts: 2
Joined: Tue Jul 04, 2017 11:47 pm

Post by pmlogo »

Thanks Robert, that is very helpful!

The '-fcmdline-buffer-bytes=<value>' option works and I can see that the initial stack pointer of the main application has been pushed lower. However, since it has no effect on the initial stack pointer of the boot-loader, it seems that I'm not able to use that area for communication between the boot-loader and application.

Therefore, we've decided to just use the debug stack area (at the very top of RAM). Even if it gets clobbered by debugging, that's OK as the data is only required for in-field firmware updates.

Paul
robertxmos
XCore Addict
Posts: 169
Joined: Fri Oct 23, 2015 10:23 am

Post by robertxmos »

I wonder if we can do a similar thing for the boot-loader stack pointer too...
Post Reply