MQX_ROM_VECTORS not taken from user_config.h

[aroste]

Hi all,

(CW 10.5, MQX 4.0.2, K60N512VLQ10)

I stuck in that issue so I come to you.  I cloned a TWR-K60D100M and copy it into my workspace.  OK

I created the FNET 2.6.3 bootloader and a release version of my application.  The application downloads and runs, but I encounter the following issue:

I found out that MQX is not using the ram vector table.  "MQX_ROM_VECTORS   0 "  is declared in the user_config.h file, then in small_ram_config.h the "#ifndef MQX_ROM_VECTORS " seems to work properly.  (Seems..)

But I can see in vectors.c that it takes the MQX_ROM_VECTORS as '1'. 

I cannot find from where it comes.  I checked in my previous project where I had a cloned BSP from twr.k60d120m and it works properly. I can see with CW in the files where the code lines are included or not (grey highlight that informs that define doesn't include that part).

Someone to help? 

Some wrong project settings? 

Thanks

BR

Stéphan

[aroste]

Hi,

Yes it is what I do in all cases. I found an error in my project too so with this highlights it confused me a lot to find out the reason.

Thanks for your answer.

[aroste]

I think I succeeded by manipulating file refresh for hours.  Then I just changed the line in small_ram_config.h and put it back (just add a space) and it has been taken in count. 

For me it is very, very very problematic to not be able to be confident in the compiler and environment.    Ho to be sure all header files are taken correctly, cannot test all functionality after every compilation or header changes...   That's worry me now in the freescale tools..

[dmarks_ls · Accepted solution]

If you're unsure whether your changes are being taken up correctly, don't just do a refresh.  Make sure you do a "clean project", then do a build; that will make sure that everything is rebuilt.  Also, when making a change like setting MQX_ROM_VECTORS to 0, make sure you rebuild both the BSP and PSP, just to be sure.  If you're cloning a BSP, make sure that your project files call out the correct subdirectory for your BSP.  I have frequently found that CW will sometimes not grey out the correct lines for a project; it usually relates to projects which don't include files in the right order, or rely on special definitions emitted by the compiler.  One way to test if a section of code really is being compiled is to put an #error directive in a code section you don't want to be compiled.  If the compiler hits the #error directive, you know that something isn't configured correctly.