Compiler/TMS320F28379D: C2000 SDRAM access with volatile keyword

This situation is discussed in the application note Accessing External SDRAM on the TMS320F2837x/2807x Microcontrollers Using C/C++.  

Thanks and regards,

-George

I understand the application note. This is addressing the use cases for C2000 compiler v6.4.0 (we are at v18.1.0 as of today). I think the volatile keyword is no longer needed for the 32-bit addressing as all pointer accesses have been considered 32-bit since SPRU514H. The only exception is symbol access, which is still 22-bit by default. Thus, I would say volatile is no longer needed for this purpose.

Consider the following cases:

int far_data[10] __attribute__((far)); // data array in SDRAM

To access the data array:

1. Directly using symbol:
far_data[0] = 10; // far attribute should make sure the compiler use 32-bit addressing

2. Indirectly using pointer:
int * far_data_p = far_data;
*far_data_p = 10; // according to the release note, starting from SPRU514H, far_data_p should always be 32-bit addressing

So, I do not see the neccessity of "volatile" keyword in any cases.

First, the use of volatile basically prevents optimization when accessing SDRAM.

Second, volatile keyword is a strong qualifier and cannot be mixed with regular type, ie. volaile int != int. In the case of accessing external SDRAM and internal SRAM, as a simple example, two set of APIs are needed:

void update_data_in_sdram( volatile int * addr, int value ); // for data in SDRAM
void update_data_in_sram( int * addr, int value ); // for data in SRAM

If I understand correctly, the above can be avoided given that since SPRU514H all pointers are considered 32-bit addressing.

Hi Cody,

Since SPRU514H, the size of pointer types has been changed to 32 bits. I do not see any reason why the compiler still uses 22-bit program bus to access memory pointed by a 32-bit pointer.

The only exception is to access memory directly using symbol, since it is still assumed to be 22-bit for performance reason; however, __attribute__((far)) on the symbol should be explicit enough to ensure the compiler not to use 22-bit address to access this specific memory with such symbol.

Or is there some misunderstanding I have regarding the compiler behavior?

The far attribute applies to the symbol, not the type. This means that once you take the address of the symbol and store it in a pointer, there is no way to know if it points to a far address. For various reasons supporting a far type attribute is difficult and poses many challenges in the language. However, the language does support volatile types and volatile for C2000 prevents accesses via the program bus. Therefore we made the decision to require all far objects be volatile. There is no way to get around this detail. All far objects must be volatile.

> The far attribute applies to the symbol, not the type

Exactly. To access far symbol directly, the compiler knows to use 32-bit address.

> This means that once you take the address of the symbol and store it in a pointer, there is no way to know if it points to a far address.

It does not matter if the pointer is pointing to a far address or near address, as long as the compiler follows the update since SPRU514H: "The size of pointer types on C28x is now 32 bits instead of 22 bits". Why would a compiler use 22-bit program bus to access a memory pointed by a 32-bit pointer?

To my understanding, the whole purpose of the update in SPRU514H I quoted is to have an unified memory access scheme, with the only exception of symbol access for performance reasons, which is properly addressed with __attribute__((far)).