That link is useful Michael. I'm starting to remember some of this, I used it when I was doing assembly code in the early '80s, similar notation anyway. I found the definition of the nvic_table, that is in a c file I had to copy into the project. It has this near the top:
Code:
// the funny looking void(* myvectors[])(void) basically it's a way to make cc accept an array of function pointers.
__attribute__ ((section(".nvic_table")))
void(* myvectors[])(void) = {
// This are the fixed priority interrupts and the stack pointer loaded at startup at R13 (SP).
// VECTOR N (Check Datasheet)
// here the compiler it's boring.. have to figure that out
(void (*)) &_stack_top,
// stack pointer should be
// placed here at startup. 0
rst_handler, // code entry point 1
nmi_handler, // NMI handler. 2
hardfault_handler, // hard fault handler. 3
// Configurable priority interruts handler start here.
empty_def_handler, // Memory Management Fault 4
...
It has a lot of interrupt definitions, and note that near the top is the rst_handler, the entry point, which might be what you're looking for. The c file has an equivalent in teensy3: mk20dx128.c where the 'vectors' section is defined and the equivalent lines are:
Code:
__attribute__ ((section(".vectors"), used))
void (* const gVectors[])(void) =
{
(void (*)(void))((unsigned long)&_estack), // 0 ARM: Initial Stack Pointer
ResetHandler, // 1 ARM: Initial Program Counter
nmi_isr, // 2 ARM: Non-maskable Interrupt (NMI)
hard_fault_isr, // 3 ARM: Hard Fault
memmanage_fault_isr, // 4 ARM: MemManage Fault
Next I looked at the generated .map files for both projects. Where the vectors section is defined (this is on my working teensy3 project) the map looks like this:
Code:
.text 0x00000000 0x4c5c
0x00000000 . = 0x0
*(.vectors)
.vectors 0x00000000 0xf8 /home/roger/workspaceCPP/Teensy_3/Release/libTeensy_3.a(mk20dx128.o)
0x00000000 gVectors
*(.startup*)
.startup 0x000000f8 0x160 /home/roger/workspaceCPP/Teensy_3/Release/libTeensy_3.a(mk20dx128.o)
0x000000f8 ResetHandler
0x00000400 . = 0x400
*fill* 0x00000258 0x1a8 ff
*(.flashconfig*)
.flashconfig 0x00000400 0x10 /home/roger/workspaceCPP/Teensy_3/Release/libTeensy_3.a(mk20dx128.o)
0x00000400 flashconfigbytes
*(.text*)
.text 0x00000410 0xb0 /home/roger/sat/lib/gcc/arm-none-eabi/4.7.3/thumb/cortex-m4/crtbegin.o
There's the 0x0400 Paul mentioned and it comes from mk20dx128.c line 161 like this:
Code:
//void usb_isr(void)
//{
//}
__attribute__ ((section(".flashconfig"), used))
const uint8_t flashconfigbytes[16] = {
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFE, 0xFF, 0xFF, 0xFF
};
These look like fuses to me but I couldn't say more than that without reading a lot more.
Over on the Stellaris the map look like this:
Code:
.text 0x00000000 0x758
*(.nvic_table)
.nvic_table 0x00000000 0x26c ./LM4F_startup.o
0x00000000 myvectors
*(.text.*)
.text.rst_handler
0x0000026c 0x70 ./LM4F_startup.o
0x0000026c rst_handler
.text.nmi_handler
0x000002dc 0x8 ./LM4F_startup.o
0x000002dc nmi_handler
.text.hardfault_handler
0x000002e4 0x8 ./LM4F_startup.o
0x000002e4 hardfault_handler
.text.empty_def_handler
0x000002ec 0x8 ./LM4F_startup.o
0x000002ec empty_def_handler
.text.main 0x000002f4 0xa4 ./main.o
0x000002f4 main
.text.Timer1A_ISR
0x00000398 0x2c ./main.o
0x00000398 Timer1A_ISR
.text.SysCtlPeripheralEnable
0x000003c4 0x4c /home/roger/src/stellaris/stellarisware/driverlib/gcc-cm4f/libdriver-cm4f.a(sysctl.o)
0x000003c4 SysCtlPeripheralEnable
.text.SysCtlDelay
0x00000410 0x8 /home/roger/src/stellaris/stellarisware/driverlib/gcc-cm4f/libdriver-cm4f.a(sysctl.o)
0x00000410 SysCtlDelay
.text.SysCtlClockSet
0x00000418 0x164 /home/roger/src/stellaris/stellarisware/driverlib/gcc-cm4f/libdriver-cm4f.a(sysctl.o)
0x00000418 SysCtlClockSet
So this doesn't have anything special at 0x400. I just checked what Paul said earlier:
Freescale Kinetis chips have 16 config bytes in flash at 0x00000400 which are similar to the AVR "fuses"
I guess the Stellaris is a TI chip not a Freescale one so we would expect it to be different.
However to get the fuses set in (actually they are "fuses") the teensy it ought to be possible to get the mk20dx128.c file and the section definitions from the ld file into your build. Good luck.
Reply With Quote
Originally Posted by dmf3030
And if you do this, whether it works or not, you really have to post pictures. I'm sure I'm not the only one who'd love to see it.
