Memory overlap in MRAM

[CarlFST60L]

Hi,

I have been doing some debugging on our application from MRAM (MQX3.5.1, CW7.1.2, 52259evb).

I have a table in MRAM at 0x1005A000. When a run my full application code, somehow the data at 0x1005A000 gets overwritten with some data (AES_KEY_TABLE below). The data is dumped to printf and its wrong, the debugger also shows the table partially overwritten.

Here is the memory map from my xMAP

# Memory map:
  v_addr   p_addr   size     name
  10000000 10000000 00000400 .vectors   vectorrom
  10000400 10000400 00000018 .cfmprotect cfmprotrom
  10000420 10000420 00000202 .Master_Boot_Page Master_Boot
  10001000 10001000 00049728 .main_application MRAM
  1005A000 1005A000 00003828 .AES_KEY_TABLE_Page AES_KEY_TABLE
  20000000 1004A728 0000073C .main_application_data ram
  2000073C 1004AE64 00000018 .romp      ram
  20000754 20000754 00000B10 .main_application_bss ram
  20001264 20001264 00000000 .kernel_data ram
  2000FFF0 2000FFF0 00000000 .end_of_kernel_data end_of_kd
  2000FA00 2000FA00 00000000 .boot_stack bstack
  2000FBFF 2000FBFF 00000000 .end_of_boot_stack end_bstack

My understanding to working out how much memory there is between MRAM base and AES table is:

MRAM BASE (0x10001000) +

main_application MRAM (0x49728) +

main_application_data ram (0x73C) +

.romp ram (0x18) 00049728

= 0x1004AE7C.

This is well away from 0x1005A000, viewing memory via the debugger shows the memory overwritten up to around address 1005A710.

I cannot think of anything else... Unless MRAM is being used as SRAM during MRAM debug? or maybe romp (rom to ram) is causing the problem?How do I check?

PS, to test, I break on the first line in MAIN_TASK and use the 'view memory' function.

[PetrL]

Hi,

it should work as you described. In M522259 BSP provided with MQX 3.5.1is MRAM Debug targets configured to be used for Code+Constant data (there are some exception - e.g.  ramdisk example, where MRAM is used as disk, formatted to FAT12 but this example does not containing MRAM target..).

To be sure, if the memory is not overwritten during runtime set "write breakpoint to the memory which gets overwritten.

You will see the code which is responsible for overwriting  your area.

If the break point is never hit then there will be some problem with linker command file or "flasher" script..

PetrL

[DavidS]

Hi Carl,

Did your project evolve from one of the demo projects?

Do you have\use #define DEMOCFG_USE_POOLS 1 ?

If yes, set to 0 or comment out.

Regards,

David