• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 101 subscribers
  • Views 1967 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.

C6748 memory alignment considerations

ReinierC
Expert 2425 points
Other Parts Discussed in Thread: OMAP-L138, OMAPL138

Hi,

I'm using the OMAP-L138 Zoom Development Kit from Logic PD to port one of our projects from the C6418 DSP to the C6748 DSP, using DSP/BIOS 5.41. I'm currently in the process of chasing some bugs in the system. At the moment I'm really struggling just to localize the bug(s) to a certain area to the code, since the same inputs from my side into the application, results in inconsistent failures. However, through various stepping excursions through the code, it appears that the failures are usually somehow related to dynamic memory allocation. I've seen this type of inconsistent behaviour when I used the PSP drivers in EDMA mode without correctly aligning my buffers, but I can't see how this is the same.

All our dynamic memory allocations are made from external mDDR RAM (except for EDMA, explained below) with a very large heap defined in my TCF script, so the problem is definitely not related to insufficient memory.

We are only using the EDMA for data transfer between the McASP and the AIC3106 codec, and the SIO buffers for this are allocated from internal RAM.

To my understanding, buffer alignment to the C6748 cache line is only required if EDMA is used and the memory in question is external memory. Is my understanding correct or am I missing something?

Also, are there any other memory considerations specific to the C6748 that I have to take into account in the way I manage memory?

Some pointer would be greatly appreciated!

Regards

  Reinier

  • 0
    Expert 1950 points

    Hello,

    Maybe advisory 2.1.17 of errata sprz301h.pdf (align to 64-bytes boundary).

    Jakez

  • 0 in reply to Jakez
    Expert 2425 points

    Hi Jakez,

    I see the errata you are refering to are only applicable to silicon revisions 2.1 and earlier. I'm almost sure I have a newer revision, but how I can check to verify this, more specifically, where can I find out what all the characters on the product code mean?

    I also believe I might also be overclocking the DSP to 432 MHz, instead of 375MHz. Will this cause any known problems?

  • 0 in reply to ReinierC
    Expert 1950 points

    Hello,

    According to the datasheet (sprs586d.pdf), rev2.1 is the last one; see markings in 6.1.2 (OMAPL138B).

    Prefer avoiding such overclocking while developing (doesn't help); you should try to find a board with a 456-MHz-rated chip.

    Jakez

  • 0 in reply to Jakez
    Expert 2425 points

    Jakez,

    Thank you for the info.

    I did try the workaround that was suggested in the errata and it made no difference to my problem. I did numerous tests on my communication between the McASP and the CODEC, the only aspect of my program that uses EDMA, on a simple reference application I wrote and works as I would expect.

    However, when I execute the same code in our main project, the application crashes (it does not throw an exception and aborts, but keeps on running, but executes other unexpected sections of code). I believe this is not related to the EDMA, but somehow to the external DDR memory. As I mentioned before, this seems like a memory management/corruption issue. Is there a specific way in which I should dynamically allocate memory from external memory or some precaution I should take? Is alignment necessary if buffers are allocated in external memory and not used by EDMA transfers?

    I also clocked the DSP to 372MHz just to be on the safe side.

    I wish I could provide you with more details, but I'm quite baffled here!

    Any help would be greatly appreciated!

    Regards

      Reinier

  • 0 in reply to ReinierC
    Expert 1950 points

    Hello,

    As far as I know, concerning heap memory allocation, the main requirement of xxxalloc functions is to provide an address aligned with the greatest element size of the processor (ie 8 bytes for C674x core) to be sure the memory chunk will fit with the intended data type (for example the compiler assumes 32-bit integers are always 4-byte aligned, see compiler UG). If using TI or any validated heap management library, it shouldn't be the problem.

    Another common cause of crash when adding only "working" pieces of code is insufficient stack size.

    Jakez

  • 0 in reply to Jakez
    Expert 2425 points

    Jakez,

    Thanks for your reply.

    I've been using 8 byte alignment so far. I'm using the MEM module in DSP/BIOS 5.41, I'm assuming this is the TI memory management library you are refering to?

    I have already checked the stack size, and I am sure its more than sufficient in size.

    Is there a guide somewhere to provide guidelines for which sections of a program should be place in either internal RAM or external RAM?

    I have also noticed that we are using assembler routines that were originally written for the C6418 DSP. Can this cause potential problems?

    Regards

      Reinier

  • 0 in reply to ReinierC
    Expert 2655 points

    Grtns,

    I take it you are using CCS3.3.  Please show us your project file (xxxxxx.pjt).

    Ltr,

  • 0 in reply to Sam Kuzbary
    Expert 2655 points

    Also, pls show your L1P, L1D and L2 cache/RAM configuration.

  • 0 in reply to ReinierC
    TI__Guru* 84110 points

    Reinier,

    Re alignment to cache line: If no bus master other than the C674x DSP accesses an external memory area, then you will never need to worry about alignment or any cache coherency commands. But if any other bus master can access the mDDR buffer areas, then you will need to do cache coherency commands and this will lead to problems if you do not adhere to cache line alignment and cache line multiples for dynamic allocation.

    Assembly routines written for the C64x DSP in the C6418 are compatible with the C674x DSP in the C6748. The only possible issues would come from hard-coded addresses or peripheral accesses. If you re-build from the assembly source file, you will get some optimization from the architectural improvements that went into the C64x+ and then to the C674x DSP cores.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Expert 2425 points

    Hi guys,

    Sorry for only replying now.

    We narrowed the memory issues down to our assembler routines that were originally written for the C6418. Although the instructions are still compatible, we found that the C674x core handles the stack differently. We found this when we compared the generated assembler files with our own assembler files. In essence we found that the our assembler routines corrupted the stack, which created all these weird and non-deterministic memory issues.

    Due to the improved performance of both the hardware and the codegen tools, we have decided to port all our existing assembler routines to C/C++.

    Reinier

  • 0 in reply to ReinierC
    Expert 2655 points

    Grtns,

    SP, DP and FP are the product of how the CGT tools handle the run time data storage architecture, and not CPU specific, hence their use when using linear assembly and assembly will differ.  Further more, certain optimization techniques will steer the compiler to make different use-case models, as well.

    Good Luck,

  • 0 in reply to ReinierC
    Expert 2795 points

    Could you tell us which compiler version includes these assembler routines?

    Best regards,

    David.