I found FPC_HAS_SYSTEMS_INTERRUPT_TABL, enabled it - but it was still broken for Thumb2 (stellaris, stm32).
For Thumb2, it was broken in the following ways: 1) Stack_top should be placed at vector 0. 2) Each address should have the LSB set - to "force" Thumb mode when the PC gets loaded with that value. I defined FPC_HAS_SYSTEMS_INTERRUPT_TABLE a little further down - so that was only enabled on ARM and AVR (trying not to break other things...) I also have some added logic in ncgutil - for M3 devices - to place the stack_top into vector 0, then place handlers for vectors 1 to TOP. The WriteVector routine for Thumb also adds an offset of 1 to each vector - so as to force Thumb mode upon load to PC. John ________________________________ From: Jeppe Græsdal Johansen <jjoha...@student.aau.dk> To: FPC developers' list <fpc-devel@lists.freepascal.org> Sent: Sun, August 21, 2011 7:27:48 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status Den 21-08-2011 17:06, Geoffrey Barton skrev: > >On 21 Aug 2011, at 15:33, John Clymer wrote: > >As part of my table-ization of cpuinfo.pas, I am including a >generic part for each (no code published for this yet.) The > >caveat to this is that FLASH size and SRAM sizes are just >set >to extremely large (1 MB each for now). Which means if the >code size exceeds the space of the device - the >compiler/linker will not catch the overflow of the available >resource. (Running objsize on the ELF file will display the >sizes - so I just run that after every successful compile.) >> As I pointed out, this will always fail because the stacktop is set beyond the available ram. It will cause an exception I think. How do you propose to be able to set the actual ram top for the generic part, or am I missing something? > > > >>Also, still testing, but I have the "interrupt" reserved >>word >>working (more or less, more testing needed.) This takes >>the >>interrupt codeword with an integer. The integer is the >>offset >>into the vectors table. If no interrupt is provided for >>the >>given address, it defaults to DefaultHandler in the startup >>file - which is just a continual loop - so one can >>breakpoint >>on it. (This can be enabled / disabled via a define in >> >>the source.) This is should only be enabled for the >>embedded >>target - but I need to double check to ensure that is the >>case. >> This is a useful development; ideally the integer would be backed by an enumeration as it is a big table. One thing which I did find missing was the interrupt enable and disable assembler codes, so I patched them with data bytes hidden in functions. The keil C compiler does not like these if you link to units doing this (throws a data/code wobbly). See the file attached to bug tracker ID0017365 for how I hacked interrupts. The CPS* instruction with the correct operand syntax was added in #18334 SVN trunk already has experimental support for the interrupt keyword. It's enabled with FPC_HAS_SYSTEMS_INTERRUPT_TABLE in fpcdefs.inc. I discovered a small bug with the current implementation which is fixed with the attached patch(which also includes some other stuff... the bugfix is in ncgutil. It didn't search the program file for interrupt handlers before)
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
