Debug problems using Bit Band Alias region

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Debug problems using Bit Band Alias region

1,996 Views
zeta
Contributor II

Hi, i have a problem when i want to debug. After following the instructions pointed in "Placing data into different RAM blocks"  i have defined a section in the Bit Band Alias region (0x22000000), so i can automaticaly place variables of bit type (aligned to 4 bytes). The problem is when i want to debug the project, the intialization secuence halts at a point and i only can see this error messages: "warning: Overlapping regions in memory map: ignoring" in gdb.
Anyway when i flash the MCU it runs normally, also i've checked that a variable placed in the new region is placed ok.

Also i'm experiencing issues at writing/reading from the bit band alias via pointers/macros, it always generates a hard fault.

Any idea?.

Thanks in advance.

Labels (1)
8 Replies

1,671 Views
lpcxpresso_supp
NXP Employee
NXP Employee

Upon further investigation, it turns out that the issue you are seeing debugging is being caused by the fact that the LinkServer debug connection provides its own memory setup to GDB covering the bit band alias region. And this is clashing with the region you are defining in your memory configuration.

This behaviour has been in place for a very long time, and has not been spotted before - and unfortunately there is no workaround possible at the debug level. This is something we will investigate changing the behaviour of in our next IDE release.

In the meantime, all I can suggest is that you will have to stick to the macro mechanism for accessing the bit band alias addressing (rather than defining an explicit memory region for the alias addresses), or else using a SEGGER or P&E debug connection instead of the LinkServer (CMSIS-DAP) one.

Regards,

MCUXpresso IDE Support

0 Kudos
Reply

1,671 Views
zeta
Contributor II

Ok, thanks a lot for your help. I will continue working with the macros and looking fordward waiting for the next IDE release!

Best regards.

Flavio

0 Kudos
Reply

1,671 Views
lpcxpresso_supp
NXP Employee
NXP Employee

Debug failure replicated when you define a bit band alias memory region. Now investigating.

Regards,

MCUXpresso IDE Support

1,671 Views
lpcxpresso_supp
NXP Employee
NXP Employee

If you want us to look at this, can you give us a cut down example that provides exact details of your memory configuration inside the IDE, the linker scripts that are used in linking, and some example code definitions and usage. Otherwise we are just guessing at what you are actually doing.

Regards,

MCUXpresso IDE Support

0 Kudos
Reply

1,671 Views
zeta
Contributor II

Ok, theres's no problem:

First here is a snapshot of the memory map extracted from the memory configuration utility in the MCUXpresso IDE:

pastedImage_2.png

Respect to linker script i let the IDE manage them (Option Manage Linker script enabled in the MCU Linker section).

As i said before when the block RAM4 is not defined i can debug normally (and of course i'm not able to place anything in RAM4 section).

Then i use this types and definitions:

Definition of pseudotype bit:

typedef Bool BIT __attribute__ ((aligned (4)));      // i define the type this way to ensure it is aligned to four bytes (it will reside in the bit band alias region), and the Bool type is a convenience since it only allows values 1 and 0.

Then when i want to define a variable of this type i use:

BIT bitTypeVar __DATA(BBARam);                       // since this is the section name you see in the memory configurator.

Then i use the variable "bitTypeVar" normally assigning values and reading it. Besides the definitions and types i'm showing to you, the problem persist although i'm not using them, put in simple way: i can only debug when there´s not a RAM section defined in the bit band alias region.

I'm not pasting the linker scripts since there are automatically generated, after a simple inspection of them i can see all the sections defined.

At this point i want to insist in that when i flash the program (via the  LinkServer GUI Flash Programmer) it works just fine but leaving it this way i loose the ability to debug the code.

Is this helpful ot there is anyhing else you need?

Regards.

0 Kudos
Reply

1,671 Views
zeta
Contributor II

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.

0 Kudos
Reply

1,671 Views
lpcxpresso_supp
NXP Employee
NXP Employee

You don't say what MCU you are using. One thing to watch is that with some parts the address of RAM doesn't match up to the start of the bitbanding region.

The bitbanding alias maps the bitband region starting at address 0x20000000. But on the LPC17xx, for example, the only RAM in that area starts at address 0x2007c000. This maps onto address 0x22f8000 in the bitband alias.

So, you need to access address 0x22f8000 to see the bitbanded aliases at address 0x2007c000. And as no memory exists at 0x20000000 on LPC17, then no bitband alias exists as 0x22000000 and so would get errors returned from the target as you report,

Regards,

MCUXpresso IDE Support

1,671 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Hi,

Can you please upload your demo project thus we can check the problem directly?

Thanks.


Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply