• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 1427 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.

F28069 CLA-to-CPU memory conflict

CCS Update Login
Prodigy 190 points

Hi,

I am using the shared memory block between CLA and CPU to transfer some 32-bit variables. From what I can see, this memory is inherently16-bit and wondered what needs to be done to ensure that the CPU performs an atomic 32-bit read since the CLA task that is writing the data is asynchronous to the CPU code reading the data.

I have also noticed that declaring a mixture of 32-bit and 16-bit variables in this shared memory causes read problems for the 16-bit variables. For example, if I create two variables, one 16-bit, the other 32-bit, and assign both variables the same value, then the 16-bit value is corrupt. On inspection in the memory browser, I notice the variable is assigned to address 0x1481 but the actual value is stored at address 0x1480. Is there an issue with odd addresses and if so what is the best way to force any 16-bit variables onto an even address? I should also say that my code is being generated using Simulink Embedded Coder (using the C2000 toolbox) so I want to avoid having to make manual edits to the auto-code.

Any help much appreciated.

Thanks

Richard

  • 0
    TI__Guru** 113655 points

    Hi Richard,

    From what I can see, this memory is inherently16-bit and wondered what needs to be done to ensure that the CPU performs an atomic 32-bit read since the CLA task that is writing the data is asynchronous to the CPU code reading the data.

    This is 32bit memory and you should be able to do a 32bit READ/WRITE operation to these memories.

    On inspection in the memory browser, I notice the variable is assigned to address 0x1481 but the actual value is stored at address 0x1480. Is there an issue with odd addresses and if so what is the best way to force any 16-bit variables onto an even address?

    If you are assigning a 16bit value to odd address, this should be fine and value should be written at correct address. Only if 32bit value get assigned to odd address then it'll be written to even address. Could you check again that this is indeed 16bit value and not 32bit value. How are you defining both variables? 

    Regards

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 190 points
    Hi Vivek and thanks for the quick response.

    After further reading I came across this paragraph in the CLA tech reference manual (SPRUGE6B) page 11:

    • CLA Data Write Bus
    The CLA data write bus has a 64K x 16 address range. This bus can perform 16 or 32-bit writes. The
    bus will automatically stall if there are memory access conflicts. The data write bus has access to the
    CLA to CPU message RAM, CLA data memory and the ePWM, HRPWM, and Comparator registers.

    I believe this reinforces your comment that a 32-bit read/write should be atomic as the bus will be stalled.

    As for the 16-bit assignment, I can confirm that I have two 16-bit variables mapped to the CLA-to-CPU shared memory at addresses 0x1480 and 0x1481, however the actual values as read by the CPU/memory browser appears to be corrupt. If I make both these variables 32-bit, then everything is fine. Both variables are being written with values smaller than 16-bit so it is not due to truncation/wrap-around.

    I'm not too concerned at the moment as the majority of my variables are 32-bit so I can just force the remaining 16-bit variables to be 32-bit, although I am curious as to why there is a problem.

    Regards
    Richard
  • 0 in reply to CCS Update Login
    TI__Guru** 113655 points

    Hi Richard,

    As for the 16-bit assignment, I can confirm that I have two 16-bit variables mapped to the CLA-to-CPU shared memory at addresses 0x1480 and 0x1481, however the actual values as read by the CPU/memory browser appears to be corrupt. If I make both these variables 32-bit, then everything is fine. Both variables are being written with values smaller than 16-bit so it is not due to truncation/wrap-around.

    What happens if you read the value from CLA itself? Do you see correct value or corrupted value. Also which variable value gets corrupted? One @0x1480 or @0x1481 ?

    Is it possible to share the project file which has this issue?

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 190 points

    Hi Vivek,

    I have discovered the issue; the CLA data types for an int type are 32-bit (16-bit for the C28x core). This causes any variable of typedef uint16 or int16 to be mapped as 32-bit and thus causes corruption of any adjacent variable. I can observe this if I create two 16-bit variables and assign constant values; the first variable reads ok but the second will be corrupt.

    The snippet below from the CLA wiki page describes this. Thanks for you help.

    Regards

    Richard

    Characteristics

    Language
    Supports C only. No C++ or GCC extension support.
    Data Types
    (NOTE THE DIFFERENCES FROM C28X DATA TYPES!!)
    • char,short - 16 bits.
    • int,long - 32 bits (int is 16 bits on the C28x)
    • float, double, long double - 32 bits
    • pointers - 16 bits (pointers are 22 bits wide on the C28x)