• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 84 subscribers
  • Views 542 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Compiler/TMS320F28035: Preventing "Prefetching Beyond Valid Memory" Errata

Pauli
Intellectual 270 points
Part Number: TMS320F28035

Tool/software: TI C/C++ Compiler

Hi

I'm having a problem with code hitting ISR_ILLEGAL trap. This started to happen after a code change, but the change isn't that closely related to the place where the illegal isr is triggered. After debugging this for quite some time I'm suspecting I'm experiencing the "Prefetching Beyond Valid Memory" errata.

I have plenty of stack left and increasing stack size doesn't help. So, I think it's not a stack overflow problem. It seems the illegal isr gets triggered from a function where I'm using DELAY_US macro. If I step through the code it works. DSP28x_usDelay is executed from ram and ramfuncs is stored in RAML1. DSP28x_usDelay is the last function in RAML1 which is almost full: 1020 of 1024 (99%) used. The last 8 words of the memory region are not unused as the errata suggests. Freeing up space in RAML1 fixes the problem.

My doubt in this is that it's very easy to fix/lose the problem with some other change which doesn't affect RAML1 in any way. Would this indicate that my assumption is wrong, and the real problem is something else?

How can I ensure that the last 8 words of a memory area are left unused? Can it be done from the linker cmd file? If I change the length of RAML1 from 0x000400 to 0x0003F8 will it do the trick or will the prefetch problem happen just earlier in the memory?

Or can it be done on the sections level? Since prefetching over the memory block boundary is ok, I want to ensure that the last words of the last memory block stay unused when a section is allocated to multiple memory blocks. For example in case:

.text               : >> FLASHD | FLASHE | FLASHF,      PAGE = 0

Best regards
Pauli

  • 0
    TI__Guru** 113755 points
    Hi,

    After L1 you have L2 RAM which is valid RAM. As long as that is available for CPU usage, it should not cause any issue and this errata does not apply to this case. You may be facing some other issue here.

    Regards,

    Vivek Singh
  • 0 in reply to Vivek Singh
    Intellectual 270 points

    Thank you. I see this was explained in example 2 in the errata, which I somehow misread. However, Could you explain what is meant by "valid RAM". Is it just any memory block regardless from how it is used or should it be program memory?

    In my case L2 is used as data memory and contains CLA data variables. So, if the CPU prefetches past the L1 end, into L2 RAM it will fetch some random variable value. Not an valid opcode.

    Couldn't find any details about how the prefetch in this processor works.

    Now that I think of it, L2 RAM is configured as cla data RAM with the following line:

    Cla1Regs.MMEMCFG.bit.RAM1E = 1;     // Configure CLA data RAM 1 (L2 RAM) for CLA use

    So, I guess it is not "available for CPU usage" and the errata applies?

    Best regards
    Pauli

  • 0 in reply to Pauli
    TI__Guru** 113755 points

    Hi Pauli,

    "Vaild RAM" means any memory block from where CPU can fetch the code even though the code is invalid. Issue happens if CPU fetch is not allowed or there is no valid memory block the  CPU fetch may cause access violation even though CPU is not going to execute that code.

    Hope it's clear.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Intellectual 270 points
    Thanks.

    Now, is there a way to ensure that the memory block doesn't get too full? Decreasing RAML1 length in the linker cmd file form 0x000400 to 0x0003F8 seems to work.

    If there is a better way, I'd like to know. This is a bit prone to break. I'll have to remember to check these through again if the memory allocation is changed.

    Best regards
    Pauli
  • 0 in reply to Pauli
    TI__Guru* 91215 points
    Pauli,

    Specifying the length of the memory block in the linker command file is the right way. The linker will only allocate to memory that is defined in the linker command file.

    Regards
    Lori
  • 0 in reply to Lori Heustess
    Intellectual 270 points
    Thanks for the help

    Best regards
    Pauli