SDRAM memory write corruption

Under the latest core writing to SDRAM a simple struct of size 1112 bytes aligned to 8 bytes using " __attribute__((aligned(8)));" then reading it back is returning memory bit flip issues. SDRAM.begin(); is used as well as a proper SDRAM.malloc(); is used -> data_storage_sdram = (DATA_FRAME_RETURN*) SDRAM.malloc((sizeof(struct DATA_FRAME_RETURN) * MAX_NUMBER_OF_ELEMENTS_SDRAM) + 256);. I have printed out the before and after at the byte level in hex for you to look at below: (I have also tried this on all 6 Gigas I own with exactly the same results)

```0 0 60000324
0 0 60000325
0 0 60000326
0 0 60000327
0 0 60000328
0 0 60000329
8 8 6000032a
40 40 6000032b

fc fc 6000032c
a9 a9 6000032d
f1 f1 6000032e
d2 d3 6000032f -----*
4d 4d 60000330
62 62 60000331
50 50 60000332
3f 3f 60000333

0 0 60000334
0 0 60000335
0 0 60000336
0 0 60000337
0 0 60000338
0 0 60000339
2e 2e 6000033a
40 40 6000033b

c8 c8 6000033c
0 0 6000033d
0 c8 6000033e -----*
0 0 6000033f
0 0 60000340
0 0 60000341
0 0 60000342
0 0 60000343

0 0 60000344
0 0 60000345
0 0 60000346
0 0 60000347
0 0 60000348
0 0 60000349
8 8 6000034a
40 40 6000034b

fc fc 6000034c
a9 a9 6000034d
f1 f1 6000034e
d2 d3 6000034f -----*
4d 4d 60000350
62 62 60000351
50 50 60000352
3f 3f 60000353

0 0 0x60000384
0 0 0x60000385
0 0 0x60000386
0 0 0x60000387
0 0 0x60000388
0 0 0x60000389
54 54 0x6000038a
40 40 0x6000038b

fa fa 0x6000038c
7e 7e 0x6000038d
6a fa 0x6000038e -----*
bc bc 0x6000038f
74 74 0x60000390
93 93 0x60000391
68 78 0x60000392 -----*
3f 3f 0x60000393

0 0 0x60000394
0 0 0x60000395
0 0 0x60000396
0 0 0x60000397
0 0 0x60000398
94 94 0x60000399
c1 c1 0x6000039a
40 40 0x6000039b

96 96 0x6000039c
0 0 0x6000039d
0 92 0x6000039e -----*
0 0 0x6000039f
0 0 0x600003a0
0 0 0x600003a1
0 0 0x600003a2
0 0 0x600003a3

0 0 0x600003a4
0 0 0x600003a5
0 0 0x600003a6
0 0 0x600003a7
0 0 0x600003a8
0 0 0x600003a9
4e 4e 0x600003aa
40 40 0x600003ab

7b 7b 0x600003ac
14 14 0x600003ad
ae fe 0x600003ae -----*
47 06 0x600003af -----*
e1 e1 0x600003b0
7a 7a 0x600003b1
b4 f4 0x600003b2 -----*
3f 3f 0x600003b3

0 0 0x600003b4
0 0 0x600003b5
0 0 0x600003b6
0 0 0x600003b7
0 0 0x600003b8
40 40 0x600003b9
8f 8f 0x600003ba
```

AND

```0 0
0 0
0 0
0 0
0 0
0 0
8 8
40 40

fc fc
a9 a9
f1 f9 1111[0]001 -> 1111[1]001
d2 e3 11[01]001[0] -> 11[10]001[1]
4d 4d
62 62
50 58 0101[0]000 -> 0101[1]000
3f 3f

0 0
0 0
0 0
0 0
0 0
0 0
2e 2e
40 40

c8 c8
0 0
0 c8 00000000 -> 11001000
0 0
0 0
0 0
0 0
0 0

0 0
0 0
0 0
0 0
0 0
0 0
8 8
40 40

fc fc
a9 a9
f1 f9 1111[0]001 -> 1111[1]001
d2 e3 11[01]001[0] -> 11[10]001[1]
4d 4d
62 62
50 50
3f 3f
```

Any ideas why this is happening or what can be done to fix it.

Start by reproducing the byte-level mismatch using SDRAM.begin(), SDRAM.malloc(), and the 1112-byte aligned DATA_FRAME_RETURN struct described in the issue. Compare the written and read-back buffers, then trace the SDRAM allocation and access path to identify the corruption. Done means the struct reads back byte-for-byte identically across the reported cases.

Written by the indexing model from the issue text.