reset / top-of-memory question

[yzoer]

Hi All,

I'm looking for a 'safe' way to store data that'll survive a software reset..

With that in mind, does anyone know if a software-reset clears memory? I'm guessing no but I haven't tried it yet. Secondly, is there a way to override the stack-pointer initialization and lower the top of memory?

-Yvo

[Ross]

Hi there,

Memory does retain state over a soft reset

[yzoer]

Thanks Ross! That's half the problem solved :-)

Are there any dependencies / assumptions on the stack before 'main' gets called? If not, it might be as simple as adjusting the stack pointer but I'm guessing it's a bit more involved. Ideally, I'd like to pass in a new memtop for the Mapper and have everything work itself out that way...

-Yvo

[Edit: I came across the ReadOnly _RamSize and an xmapper option called --image-size but passing in different values doesn't seem to move the SP.]

[Ross]

WE used a similar trick in the USB Audio code to retain some state when rebooting into DFU mode. Do you have access to that codebase?

[yzoer]

I haven't looked at it but will at lunch. Looking at the code it seems the SP gets loaded from a resource register (if I'm right) which presumably gets passed in by the mapper? Additionally, are any of the linker symbols available, like bss start/end.

-Yvo

[segher]

Looking at the code it seems the SP gets loaded from a resource register (if I'm right) which presumably gets passed in by the mapper?

That's ps[0x0b], start of RAM. It is initialised by the boot ROM (to 0x10000),
and you generally do not want it changed. It is used for the event vectors
(and other things I guess, can't quite remember).

The application start code adds a number (size of RAM) to it; it gets that number
from the last word in the text segment. I'm sure there is a symbol name for it
as well ;-)

Then finally, it extends the stack 0x100 bytes down. Which is good, because the
top of RAM is used by the debugger already ;-)

[yzoer]

Segher (as usual) to the rescue! Thanks for the lead!

Are those 256 bytes allocated / used at all in release? If not, I may not need to alter the SP and use that instead! If anyone here knows if xmap --image-size impacts the size of memory footprint at all, that'd be grand. Are the .bss symbols available to XC / C?

Request for the XMOS web-master(s): Any chance we can get some kind of 'Thanks' or '+1' system for folks like Segher, Bianco et al? These guys deserve some recognition, even if it's virtual :-)

-Yvo

[yzoer]

Alright, so the magic word(s) here are:

-Xmapper --image-size -Xmapper NNNN

where NNNN is the new memory size. The trick here is that you need to pass them into the 'Tool specific Flags' section under Xmapper or they won't work.. at least under 11.11.0 ( yes, I'm aware that's an older version :-) Just have too much code invested and to go through any potential hassles right now )

Again, cheers to the usual suspects for pitching in!

-Yvo

[segher]

Are those 256 bytes allocated / used at all in release?

The (default) debugger uses memory from 0x1ff80 upwards, but not all
of it; I've used the very highest words before. I've seen other things use
it as well, but you're probably safe if you only use "official" libraries.

[yzoer]

So I've been messing around a bit with this and it looks like *something* is scribbling over memory ranging from, at least where I was testing, 0x1ff00 upwards. It looks pretty consistent as well so I'm guessing something gets uploaded there during initialization from eprom. 0x1fff0 seems fine...
Lowering the top of memory doesn't seem to make a difference.

Can anyone at XMOS confirm here if that's the case? I need a safe area where I can keep data the survives a reset and want to make sure that's not getting scribbled over during chip-revisions and what not.

I only tested this with a handful of bytes / locations but if anyone's interested I can see if I can do a full-range check..

-Yvo