Compiling FreeRTOS + SMAC Demo for KW21D256: Interrupt problems

[rafaelsend]

Hello-

I'm relatively new to this, and part of my current task is to port a custom SMAC application to the KW2. As a starting point, I want to run the Connectivity Demo as a task in FreeRTOS. I started with this using Processor Expert: Tutorial: Freedom with FreeRTOS and Kinetis-L | MCU on Eclipse which was relatively easy to move to the TWR-K21D256 board I have.

Now, as I'm adding in components of the Connectivity Test project, I'm getting strange compilation errors. Namely:

"c:/freescale/cw mcu v10.5/cross_tools/arm-none-eabi-gcc-4_7_3/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld.exe: RTOSCreationTest.elf section `.interrupts' will not fit in region `m_interrupts'

c:/freescale/cw mcu v10.5/cross_tools/arm-none-eabi-gcc-4_7_3/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld.exe: region `m_interrupts' overflowed by 324 bytes"

This is strange to me, as it looks like it's not even trying to place the vector table in the area it's supposed to go (0x00000000 - 0x0000144, right?). Experimentally, I doubled the size of MemoryArea1 in Processor Expert (m_interrupts) to 288 to see what happens. This builds, but obviously doesn't work.

Question is, why is m_interrupts section trying to start elsewhere than zero? There's no bootloader, since the board uses OpenSDA to load code.

Has anyone run into this before, and if so, how to proceed?

Thanks,

Rafael

[mjbcswitzerland]

Hi

A KL processor normally requires 192 bytes space for its interrupt vector. A K21 requires 324 bytes.

Since you are getting an overflow of 324 bytes it sounds as thouigh the linker script is not reserving any space - and you would need to reserve at least 324 to make them fit.

However, if the KL based project is not reserving space it is presumably not using then there but locating then in SRAM (and pointing the vector table offset register there). If this is the case, locating the vectors in Flash will also have no affect (assuming some will be there but the other will be working from SRAM).

The reset vector will be at 0x00000000 but needs only to be 16 bytes in size if no interrupts are there. Check the original size and whether interrupts are put to SRAM or not - then adapt any new interrupts to use the same method (or the original to use the same as the new one).

Regards

Mark

[rafaelsend]

Hi-

I forgot to say that the .map file shows that the space appears to be allocated correctly. Unless the .map file doesn't correspond to what's actually going on, I would assume the space is being reserved, no?

Thanks,

R

[BlackNight]

Not sure what you added from this 'connectivity test project'? So it seems that some additional enteries get added to the vector table. From the map file you should see what gets added to the vector table section, or search for things like ".vectortable" in your sources? Maybe you two vector tables defined?

"overflowed by 324 bytes" tells me that you have the vector table linked twice.

Erich

[rafaelsend]

Erich-

Possible, yes. The Connectivity Test project was generated with Beekit, I think. Part of the code that I added (in addition to the application itself) was the PLM directory, which I guess is Beekit's way of initializing the hardware.

It seems like FreeRTOS in CW has its own way of doing this, so there may be multiple definitions of hardware. However, they do it in different ways (e.g the PLM directory has an ctl0 startup file, whereas CW generates an _arm_start.c file), and I don't know what which parts are exactly redundant. I'm guessing FreeRTOS doesn't know anything about the radio hardware, so I should probably be keeping some parts of the PLM directory.

But, I don't know enough about the differences between the two yet, I'm very new to this stuff...

R

[BlackNight]

Yes, FreeRTOS does not know or assume anything about the radio hardware. It looks like the BeeKit comes with its own vector table, and with the other vector table you have now twice the vectors.

Same for the startup code I guess.