[SD CARD] Writes strange addresses (offseted?!)

[KanyeKanye]

I have got a code that generates random buffer, sets its beginning to a phrase "sector ####" and writes buffer to next and next sectors.
After writing it is checking, if buffer was written correctly.

When reading card on computer, it turns out that on address 0, there is phrase "sector: 2048". Why sector address is offseted?!

Code: Select all

	char* buffer_write = heap_caps_malloc(s_card->csd.sector_size, MALLOC_CAP_DMA);
	char* buffer_read = heap_caps_malloc(s_card->csd.sector_size, MALLOC_CAP_DMA);

	esp_err_t ret;
	for (size_t sector = 2; ; sector++) {
		fill_buffer(sector, buffer_write, s_card->csd.sector_size);
		sprintf(buffer_write, "sector: %d / rand: ", sector);
		ret = sdmmc_write_sectors(s_card, buffer_write, sector, 1);
		if (ret != ESP_OK) { ESP_LOGE(TAG, "sdmmc_write_sectors returned rc=0x%x", ret); return; }

		ret = sdmmc_read_sectors(s_card, buffer_read, sector, 1);
		if (ret != ESP_OK) { ESP_LOGE(TAG, "sdmmc_read_sectors returned rc=0x%x", ret); return; }

		if (memcmp(buffer_write, buffer_read, s_card->csd.sector_size) == 0) {
			ESP_LOGI(TAG, "READ-WRITE sector %d : OK", sector);
		} else {
			ESP_LOGI(TAG, "READ-WRITE sector %d : ERROR", sector);
		}
	}
	ESP_LOGI(TAG, "Koniec");

[ESP_igrr]

Can you try reading from /dev/rdiskN instead?

Also, why does the loop not have an exit condition? What happens when you write past the total sector count of the disk?

[KanyeKanye]

Couple of cards that I have and test are 16GB or more. Writing 16GB in 512blocks with logging between will took lots of time. I didnt waited so long. Loop is intentionally without end condition because I will never exceed cards' last sector in these tests.
To be exact I have tested both sdmmc and spi modes.
On the computer I am reading from /dev/disk2s1 (cant add "r"). Nevertheless reading with HxD on windows gives the same result- high sectors (not always 2048 for sector zero) are written into lower sectors.
Whats more function always result in READ-WRITE sector XX : OK (buffer read is the same as written)! Searching then, with hex editor on the computer, for written (to low sectors eg. 200, 500) buffer finishes without results!

Please test it on your cards and boards.

[KanyeKanye]

Another card test. There sector 8192 is written to sector address zero.

[ESP_igrr]

On the computer I am reading from /dev/disk2s1 (cant add "r").

Unless you read from /dev/rdiskN or /dev/diskN (by your screenshots I assume you are on mac OS, and both of these exist on macOS) you will be getting the same result.

You see, you are writing the disk starting from the sector 2. This preserves the MBR which is located in the sector 0. So your OS still thinks that the disk is partitioned. In addition to creating a block device for the entire SD card (which is /dev/rdiskN or /dev/diskN), it creates block devices for individual partitions (/dev/diskNs1, and others if the card had more than one partition). Depending on how the card was partitioned, the first partition may very well start from sector 2048 or 8192. So when you inspect the contents of that partition via /dev/diskNs1, you are seeing the contents starting from that sector.

I ran the code attached to your first post (removing the "fill with random data" part to make hexdumps easier to read), and then ran:

sudo hexdump -C /dev/disk4 | less

Scrolling past the first two sectors (which haven't been written by the program):

Code: Select all

000003e0  e7 ff 44 70 a3 1f 4a 27  39 80 b1 01 93 0c df 7f  |..Dp..J'9.......|
000003f0  73 80 6d 44 c6 ab 50 6a  e6 4e e0 76 f1 1e 61 00  |s.mD..Pj.N.v..a.|
00000400  73 65 63 74 6f 72 3a 20  32 20 2f 20 72 61 6e 64  |sector: 2 / rand|
00000410  3a 20 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |: ..............|
00000420  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000600  73 65 63 74 6f 72 3a 20  33 20 2f 20 72 61 6e 64  |sector: 3 / rand|
00000610  3a 20 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |: ..............|
00000620  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800  73 65 63 74 6f 72 3a 20  34 20 2f 20 72 61 6e 64  |sector: 4 / rand|
00000810  3a 20 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |: ..............|
00000820  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000a00  73 65 63 74 6f 72 3a 20  35 20 2f 20 72 61 6e 64  |sector: 5 / rand|
00000a10  3a 20 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |: ..............|
00000a20  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

So "sector: 2" string was written at offset 0x400, as expected.