ESP32 Forum

Posted: **Fri Mar 22, 2019 12:15 pm**

Hi All
I'm facing something I cannot understand. please see below :

typedef struct BroadcastAudioExtension
{
	char Description[256];			// 000-255 
	char Originator[32];			// 256-287 
	char OriginatorReference[32];		// 288-319
	char OriginationDate[10];		// 320-329
	char OriginationTime[8];		// 330-337 
	uint32_t TimeReferenceHigh;		// 338-341 
	uint32_t TimeReferenceLow;		// 342-345 
	uint16_t Version;			// 346-347 
        uint8_t  UMID[64];			// 348-411 
        uint16_t LoudnessValue;			// 412-413 
	uint16_t LoudnessRange;			// 414-415
	uint16_t MaxTruePeakLevel;		// 416-417
	uint16_t MaxMomentaryLoud;   		// 418-419
	uint16_t MaxShortTermLoud;     		// 420-421
	uint8_t Reserved[180];	        	// 422-601
	char CodingHistory[64];			// 602-665
}

The above struct size is 666 bytes as described in the comments.

Code: Select all

BroadcastAudioExtension headerBwf = {0};
ESP_LOGI(TAG, "header:%d", sizeof(headerBwf));

The above prints 668 instead of 666 !!

With further investigations, I'm logging the start address of each element of the structure :

ESP_LOGE(TAG, "Description %p", &myBwfHeader->Description[0]); -> 0x3ffe6eec
ESP_LOGE(TAG, "Originator %p", &myBwfHeader->Originator[0]); -> 0x3ffe6fec Correct
ESP_LOGE(TAG, "OriginatorReference %p", &myBwfHeader->OriginatorReference[0]); -> 0x3ffe700c Correct
ESP_LOGE(TAG, "OriginationDate %p", &myBwfHeader->OriginationDate[0]); -> 0x3ffe702c Correct
ESP_LOGE(TAG, "OriginationTime %p", &myBwfHeader->OriginationTime[0]); -> 0x3ffe7036 Correct
ESP_LOGE(TAG, "TimeReferenceHigh %p", &myBwfHeader->TimeReferenceHigh); ->shows 0x3ffe7040 NOT Correct
ESP_LOGE(TAG, "TimeReferenceLow %p", &myBwfHeader->TimeReferenceLow); -> 0x3ffe7044 Correct
ESP_LOGE(TAG, "Version %p", &myBwfHeader->Version); -> 0x3ffe7048 Correct
ESP_LOGE(TAG, "UMID %p", &myBwfHeader->UMID[0]); -> 0x3ffe704a Correct
ESP_LOGE(TAG, "LoudnessValue %p", &myBwfHeader->LoudnessValue);

As you can see above the member OriginationTime which is defined as 8 bytes occupies 10 bytes in total, 0x3ffe7040 - 0x3ffe7036 = 10, and not 8 as expected, this creates a 2 bytes offset in the structure.
I definitely cannot understand what could produce this issue.

Any help would be greatly appreciated, thanks !

Posted: **Fri Mar 22, 2019 1:03 pm**

Structure data is aligned to 4. Try:

Code: Select all

__attribute__((packed))

https://github.com/espressif/esp-idf/bl ... ocol.h#L49

Posted: **Fri Mar 22, 2019 1:13 pm**

__attribute__((aligned(2),packed)) did the job

Thanks, you saved my day !!!

Posted: **Fri Mar 22, 2019 2:28 pm**

I am stumped as well. Just using these in the struct (I removed the 2 uint32_t 's from it) you get 658 which you should, and all is well.

Code: Select all

	uint16_t Version; 			// 346-347 
	uint16_t LoudnessValue; 			// 412-413 
	uint16_t LoudnessRange; 			// 414-415
	uint16_t MaxTruePeakLevel; 		// 416-417
	uint16_t MaxMomentaryLoud;    		// 418-419
	uint16_t MaxShortTermLoud;      		// 420-421
	char Description[256]; 			// 000-255 
	char Originator[32]; 			// 256-287 
	char OriginatorReference[32]; 		// 288-319
	char OriginationDate[10]; 		// 320-329
	char OriginationTime[8]; 		// 330-337 
	uint8_t  UMID[64]; 			// 348-411 
	uint8_t Reserved[180]; 	        	// 422-601
	char CodingHistory[64]; 			// 602-665

Yet when you add these:

Code: Select all

	uint32_t TimeReferenceHigh; 		// 338-341 
	uint32_t TimeReferenceLow; 		// 342-345

You get 668, instead of 666. So now confused, I wanted to prove that uint32_t was really 4 locations each. So I removed all the variables and just used these:

Code: Select all

	uint32_t TimeReferenceHigh; 		// 338-341 
	uint32_t TimeReferenceLow; 		// 342-345

Sure enough I got a result of 8. Ok... that makes sense, but then why adding these 2 variables which are 8 locations to the sum of 658 (before adding them), wind up adding to 668 baffles me.

Posted: **Fri Mar 22, 2019 3:43 pm**

Problem was coming from char OriginationDate[10]; that was not aligned to 4 bytes.
Replacing this char OriginationDate[10]; with char OriginationDate[12]; also resulted in 668, which makes sense once you know the alignment is 4 bytes.

ESP32 Forum

Weird RAM alignment

Weird RAM alignment

Re: Weird RAM alignment

Re: Weird RAM alignment

Re: Weird RAM alignment

Re: Weird RAM alignment