In first place: thanks for the reply.
'LPCX support': thanks for pointing me that, i've already see that issue in another post and adapted my code accordingly. So i have no problem now reading/writing in the bit band region through the bit aband alias with macros. Also I can debug ok.
I'm working with a LPC1769 with the evaluation board OM13085, i've just installed MCUXpresso IDE 10.1.1_606. By the way I was following this idea:
http://www.micromouseonline.com/2013/01/13/an-improved-bit-banding-approach/
What i'm looking for is to bring back the pseudo data type 'BIT' tha was used in PIC platform, (is not that i miss it :smileyhappy:) but i think is really practical to define variables and let the linker place them abstracting me from doing it (i'm programming in C), with macros i need to take control of where is any of them and i have a lot distributed by many modules, also i can´t see the memory usage after build since in fact i'm using pointers. Finally i'm porting a project from PIC platform and by this way it's easy to adapt.
The thing is that i've defined two memory regions:
1. RAM2 in 0x2007c000 of size 0x100, this is reserved for bits. So the linker don't use it for anything else.
2. RAM4 in 0x22f80000 of size 0x2000 for aliasing the bits previously reserved.
With that in mind i can define variables aligned to four bytes and place them in RAM4 so the linker takes care of them. Also the code looks very well organized and coherent without macros in between the logic.
At this point i can build correctly, i can see in the memory usage section that a variable of size 4 is occupying space in the RAM4 region. I can flash the mcu using that variable and check that it's working ok. The problem is when i want to debug: it halts when is starting with the error mesage stated in the first post, i've checked that when i undefine the section RAM4 it comes back to life again.
At this point i'm suspecting of an IDE/gcc/gdb problem or some script that is not taking into account RAM4 section when debugging.
Any ideas?
Regards.
PD: sorry i can't include any code because is property of my company. Anyway i think the problem is easy to reproduce and i don't see relation of it at logic level.