Here is what I have in tinyclr.map
My code actually get’s farther than I thought:)
But on the SmartPtr destructor it goes back to FirstEntry.s FaultHandler
Here’s my translation to GCC:
SmartPtr_IRQ::~SmartPtr_IRQ()
{
/*
Restore();
LDR r1,[r0,#__cpp(offsetof(SmartPtr_IRQ, m_state))]
MSR PRIMASK,r1
BX lr
*/
asm(“LDR r1,[r0,%0]” :: “i” (offsetof(SmartPtr_IRQ, m_state)));
asm(“MSR PRIMASK,r1”);
asm(“BX lr”);
}
The disassembly looks good, I have no duplicate BX lr under GCC 4.6.2 (Sourcery Light).
I do not really understand what this code is all about.
What could be the cause for a fault when returning from here? Any thoughts?
I agree with Errol. Although it is 0x88 bytes which is 136 bytes, but still less than the table size. Looks suspicious. I have checked original STM32Stamp solution, they allocate a little bit over 500 bytes.
You don’t need to allocate space for any vectors past the last one you’re going to use. If you accidentally enabled one and jumped to it, the results would be bad, however.
See my stackoverflow question here: How does the ARM linker know where the exception table stops? - Stack Overflow
But placing half the vectors over non-existent ram means that RLP will NEVER be able to use those interrupts…
136 bytes gives us 33 to be the highest index for an “allowed” interrupt. Just the CPU_GPIO_Initialize function activates EXTI15_10_IRQn which is 40 - already above the allocated space. Not good.
One more thing about vector table. For STM32F4xx chips the size of the table should be 98 not 84.
Certainly not good. Jumps to random spots in memory are at best disastrous :o
I’m wondering if Oberon took an existing port as the basis of theirs without working through some of this stuff rigorously, then GHI did the same.
Ok I found it! There is 512 bytes reserved for vectors which are located at 0x20000000
Heap starts at 0x20000200 reserving 0x200 for vectors (512 bytes)
Look at the very first line in interrupt controller init method.
I see that the address of 0x20000000 is assigned to the table pointer.Where is 0x200 come from?
Wouldn’t it make more sense to handle that through the scatter file?
The scatter files are built automatically, I believe, from the XML files during the build.
I think that your .map file produced by the linker would be the final word on what happened, but I’m way beyond my meager skills here.
In scatterfile_tinyclr_rvds.xml, line 26-27 there’s this:
<Set Name="Heap_Begin" Value="0x20000200"/>
<Set Name="Heap_End" Value="0x2001BFF8"/>
I think we are talking about custom heap.
Custom heap is there, but the numbers seem… wrong… to me:
<Set Name="Custom_Heap_Begin" Value="0x1000FF70"/>
<Set Name="Custom_Heap_End" Value="0x1000FFF8"/>
It does say it’s used for the vector table, and that would give it 88 bytes. There’s something going on, though, because in FirstEntry.s (line 50) it seems to reserve enough space for 84 vector table entries. There’s magic here I don’t understand. I’ve only ever dug into much simpler examples.
@ godefroi 
Yes,that what has started the whole conversation since Errol asked the question
http://www.tinyclr.com/forum/20/4691/#/12/msg62186
It is not 88 it is 136 by the way. Gus already pointed that they force pointer to a completely different location at 0x20000000,then the one that is set in scatter (xml) file.
The question is is this the right/safe way of doing it or is it better to fix scatter (xml) file.
Sorry, we’re way ahead of me here and it’s interesting, so consider me your kid brother who’s trying to keep up 
Like I said, this is certainly much more complex than anything I’ve come across before. It makes the port much more difficult to understand and follow along with, if nothing else. In most of the other projects I’ve gone over (and done myself on the Discovery) there’s a simple vectors.s file that sets up the initial stack pointer, the vector table, and then branches to some main in a separate C file. That’s pretty simple to “get” and harder to screw up. I even came across an example that has no .s files at all, and sets up the vector table right in C code. That may be something specific to GCC, however.
It may be instructive to examine the other ports and see how they accomplish this sort of thing?
It is interesting indeed. Every time I look at porting kit code I learn something new. Just keep looking we’ll get there.
just question… why do you do not look closer the K60 port?
it does compile clean with GCC… i think the startup and vector code for M4 is done properly there both for RVDS and GCC toolchains
Antti
I don’t see a K60 port in the source tree…?
http://kinetismf.codeplex.com/
unfortunatly we only have a TOWER with Coldfire and KWIKSTART-K40 rev 4 in out office, so we have not actually tested the K60 build, I was thinking to try the K60 native sample on K40 i guess it would fit and give some hint if the cortex-M4 base port is working or not.
K60 seems to be inactive/abondoned but the processor support seems to be done rather nicely, at least there is GCC/RVDS built in properly
Antti