• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 395 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Managing big arrays on RM48 with EMIF

Hector_Tortosa
Intellectual 475 points

Hi,

I have developed some test for my Internal RAM, External RAM and Internal Flash.

So I create an array like this:

  uint16_t source[DATA_SIZE];

With the destiny address

  uint32_t target = 0x80000000;

It writes and compares correctly when the size is 512. This checks that my SDRAM works.


The problem becomes when the DATA_SIZE is bigger than 512. I get a memory abort and I can see that the code crashes on __aebi_memcpy8.

I am running this test because I want to make sure that my RM48 HDK has the SDRAM configured properly, as in my main code I'm getting other memory aborts.


I was wondering if both aborts have some kind of relationship and if missed any configuration.

In other hand, I have the HDK SDRAM chip IS42S16400F-7BL running at 220Mhz, so I have the clock for the EMIF  at 31.5 Mhz (so I avoid timming issues)

Any help?

Thanks,

  • 0
    TI__Guru 68920 points

    Hector,

      uint16_t source[DATA_SIZE];

    source is a pointer to a uint16_t because it has the [] array notation.  

    But

      uint32_t target = 0x80000000;

    target is not a pointer,  it is just a variable.  it probably will go onto the stack.

    I'm not sure you are actually checking your SDRAM.  You may just be crashing because you are corrupting the stack.

    Aside from this, you can find out what address caused the abort by checking the "Fault Status and Address Registers" in the System Control Coprocessor.  These are documented in the Cortex R4 TRM (an ARM Ltd. document).

    Once you have an idea of the address causing the fault you can confirm if it's actually in the SDRAM or if it's somewhere else because of a stack corruption.

    If it's in the SDRAM the next thing to check would be your MPU settings.  Did you enable the MPU and if so did you map the SDRAM.  If you did then are you trying to access the SDRAM with the CPU in the correct privilege mode?

    I'd work the list from top to bottom,  the last things I mentioned are probably less likely.  I'm thinking stack corruption unless it was just a typo in your post.

  • 0 in reply to Anthony F. Seely
    Intellectual 475 points

    Hi Anthony,

    My Apologise for dont have updated before.

    Big arrays where going to the SDRAM, as we have an RM48 we have some issues with the STM which are limiting the things that we can and can't.. a bit pitty situation.


    Thanks anyway for your reply, we hope the silicon fix comes soon.

    Regards,