• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 2 answers
  • Subscribers 29 subscribers
  • Views 2888 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.

FreeRtos HEAP on RM48L952HDK SDRAM

Hector_Tortosa
Intellectual 475 points

Hi,

I'm trying to use the External RAM for allocate 4 MB of HEAP, as my product will be storing big data on the RAM, so I need to allocate a lot of memory.

I have made a test program for check my SDRAM. My SDRAM is not using the internal RAM at all, runs from the first 4MB of the SDRAM and test the other 4MB.

I've used 4 tests from the internet, a test that we used for other products and a custom exhaustive test (erase-write-read,compare, address bus, data bus, etc etc).

All of them work.

But when I try to run the blinky demo on the SDRAM it fails, getting to "prefetch". Of course I tried the same test on the RAM and works correctly.

Does someone have experienced something similar?

It's possible to put the heap on the SDRAM or there is some hw limitation?

Thanks.

  • 0
    TI__Mastermind 49120 points

    Hi Hector,

    Firstly, there are some constraints on external memory accesses on the RM48x MCUs. Specifically, burst mode accesses to external memory must be avoided. Heap and stack manipulation are typical conditions that take advantage of burst writes to optimize external memory bandwidth. Since you do have 4MB of data being stored in the heap you do need to use an external memory. In this case you will need to be careful to make sure that burst writes are not performed to external memory.

    Are you also running code from external SDRAM? I presume you start code execution from internal memory and then copy over the code you want to run into external SDRAM. Do you have the Memory Protection Unit enabled? The access privileges for the memory range for SDRAM is marked as non-executable. This would cause the prefetch abort if you execute code from a region marked as non-executable.

    Let me know.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 475 points

    Hi Sunil,

    Thank you for your reply,

    I have configured the MPU as follows

    However still got prefetch Entry at some point.

    Not sure if I missed anything..

    Im Using the XRM48L952 HDK at 220Mhz, the EMIF at 55Mhz.


    Thanks,


    Hector.

    Update: Sometimes while running the code the program skip some instructions (memcopy is never done) however if I step through then it works as should be.


    There is no recommended configuration for the SDRAM?

  • 0 in reply to Hector_Tortosa
    Intellectual 475 points

    The SDRAM is the one of the RM48HDK, I believe is the same that the TMS570HDK,

    IS42S16400F-7

    I'm aware that one of the employees, Anthony, is using it. 

    Any kind of assistance would be appreciated.


    Thanks.

  • 0 in reply to Hector_Tortosa
    TI__Mastermind 49120 points

    Hector,

    For some reason I did not get the notification of your earlier post. Sorry about that.

    As I understand you are executing code out of the first 4MB of SDRAM and testing the other 4MB. The R4 CPU only allows code execution out of a memory defined as "normal" type. Also, as a result of a bug in silicon, burst writes to external normal-type memory are not supported.

    You have configured the entire SDRAM as "strongly-ordered" type. This will cause a prefetch abort when you execute code from SDRAM. You need to configure the external SDRAM as "device" type, program your code into SDRAM, and then configure the first 4MB as "normal" type before you call the function that executes out of the SDRAM.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 475 points

    Hi Sunil,


    That is correct, I forgot to update the image, as I already did that change.

    However, I keep experiencing incorrect behaviour, like instructions missed.

    Example:

    (1)- memset all area to FF

    (2)- memcpy array_1 (filled with 0x99 )

    (3)- memcpy array_1 into array_2 ( blank array )

    (4)- memcmp array_1 with array_2

    The step (2) never happens. But If I put a breakpoint and I step through the dissasembly it's done correctly.

    In other hand, and for give you more information,  I'm trying to run the FreeRTOS demo on the board under the following circumstances

    - Internal RAM as readwrite and FreeRTOS Heap location -> Works

    - External RAM as readwrite and Internal RAM as Heap location -> Works

    - Internal RAM as readwrite and External RAM as Heap location -> Doesn't Work

    - External RAM as readwrite and FreeRTOS Heap location -> Doesn't Work

    So actually and for sumarize:

    - I can run code from SDRAM correctly

    - I can use the SDRAM as readwrite

    - I can't use the SDRAM as FreeRTOS Heap

    But since I need to allocate big blocks of memory (up to 4 MB) I can't use the internal RAM. So I need to use the external.

    I'm aware that  has a TMS570 HDK with the SDRAM working properly. The TMS570 and RM48 share SDRAM chip, maybe he could throw a bit of light on this too? Or publish a recommended configuration?

    Regards and thank you for your help.

  • 0 in reply to Hector_Tortosa
    TI__Mastermind 49120 points

    Hector,

    The Rm48x MCUs have an issue with the external memory interface so that you cannot use a burst write to store data in external memory. Routines such as memset and memcpy use ARM store-multiple (STM) instructions to store data to external memory, as expected. This is a problem.

    The compiler included inside CCS has a workaround implemented for this issue. There is a switch called "--no_stm" which needs to be manually enabled as part of your compile options. Any C-source code file that accesses external memory needs to be compiled with this option enabled. e.g. the file that calls the memset and memcpy routines.

    Can you try enabling this switch and see if your code works as expected?

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 475 points

    Hi Sunil,

    Thank you for your reply.

    Is this option available in IAR Workbench?

    Regards,

    Hector.

  • 0 in reply to Hector_Tortosa
    TI__Mastermind 49120 points

    Hi Hector,

    Unfortunately IAR has not been able to implement this workaround in their compiler products due to resource/priority limitations.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 475 points

    Hi Sunil,


    Can you provide more information?

    I can't find any referece about the "no_stm" in the CCS Manual.

    We are using IAR 6.5 and due company licenses is not possible to switch to CCS.

    Regards,

    Hector.

  • 0 in reply to Hector_Tortosa
    TI__Mastermind 49120 points

    Hi Hector,

    You are correct. This option is a "hidden" option and is not available for configuration using the CCS GUI. Information below is pasted from the readme.txt file that is installed under the compiler folder: C:\ti\ccsv6\tools\compiler\arm_5.1.7 (assuming CCS installation under the C:\ti folder).

    ===============================================================================
    4) Silicon Exception in Burst Write to External Memory
    ===============================================================================

    To work around the silicon exception in burst write to external memory, you can use "--no_stm" option. It will translate a single STMXXX family instruction to a sequence of STR or VSTR instructions.

    This option will also direct all calls to memset/memcpy to a different version (no_stm_memset/no_stm_memcpy) in the RTS library.

    The option is a hidden option at this time and is not available for configuration using CCS. It needs to be manually added to the compilation script/command.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 475 points

    Hi Sunil,

    IAR doesn't have a solution for this, since affects to the compiler.

    Is this problem avoided using the asynchronous RAM? 

    Or will be solved in future revisions of the RM48?

    Thanks.

  • 0 in reply to Hector_Tortosa
    TI__Mastermind 49120 points

    Hi Hector,

    Unfortunately this issue affects both the synchronous and asynchronous interfaces to external memory. It is being addressed in a silicon update and will be available some time next year. I do not have the exact schedule and will let you know as soon as I have more information.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    TI__Mastermind 49120 points

    Hi Hector,

    There is one option that could be useful - you can compile all functions that access external memory using the TI CodeGen Tools (CGT) with the recommended workaround, and compile them into a library. You can then link in functions from this library along with other source code using the IAR toolset.

    Regards, Sunil