Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error initiating sdhc disk #15444

Closed
lucaspeixotot opened this issue Apr 14, 2019 · 3 comments · Fixed by #17700
Closed

Error initiating sdhc disk #15444

lucaspeixotot opened this issue Apr 14, 2019 · 3 comments · Fixed by #17700
Assignees
Labels
area: Disk Access bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@lucaspeixotot
Copy link
Contributor

lucaspeixotot commented Apr 14, 2019

I tried to run samples/subsys/fs and I got error in disk_access_init() function. Tracking the problem, I noticed that the error was at the beginner of the communication between mcu and sdhc, when the mcu needs to send some CMD messages to initiate the communication. The error was, more specifically, in the sending of CMD9(SDHC_SEND_CSD) message.

(file disk_accesss_sdhc.c, sdhc_detect function, line 754)
/* Read the CSD */
	err = sdhc_cmd_r1(data, SDHC_SEND_CSD, 0);
	if (err != 0) {
		return err;
	}

	err = sdhc_rx_block(data, buf, sizeof(buf));
	if (err != 0) {
		return err;
	}

If we look sdhc_cmd_r1_raw() function, which is called inside sdhc_cmd_r1() function, we will see that we are discarding a byte with this code

(file disk_accesss_sdhc.c, sdhc_cmd_r1_raw function, line 457)
/* Ensure there's a idle byte between commands */
	sdhc_rx_u8(data);

I think that this is the problem, because according to this table we can't discard every time,

2019-04-14-144849_910x463_scrot

there is some commands that have a data packet response after R1, R3/R7 response, so the existence of the code above is eating the message token of data packet response.

To solve this bug I just replace the code above with this if statement

	if (cmd != SDHC_SEND_CSD && cmd != SDHC_SEND_CID &&
	    cmd != SDHC_READ_SINGLE_BLOCK && cmd != SDHC_READ_MULTIPLE_BLOCK &&
	    cmd != SDHC_WRITE_BLOCK && cmd != SDHC_WRITE_MULTIPLE_BLOCK) {
		sdhc_rx_u8(data);
	}

and the sdhc disk was initiated and mounted successfully. I do not know if this is the best solution, but is the solution that worked for me until now.

@edit: I'm sorry, I think that I was not clear, I forgot to mention that the error is in sdhc_rx_block, after send SDHC_SEND_CSD. In this portion of code

	if (token != SDHC_TOKEN_SINGLE) {
		/* No start token */
		return -EIO;
	}

The data packet response token was lost.

@lucaspeixotot lucaspeixotot added the bug The issue is a bug, or the PR is fixing a bug label Apr 14, 2019
@nashif nashif added area: Disk Access priority: low Low impact/importance bug labels Apr 16, 2019
@Pathak94
Copy link

Thank you for the fix! I also encountered this issue with nrf52840_blip board, by doing the fix you suggested, the problem is solved. Will you send a PR for this?

@lucaspeixotot
Copy link
Contributor Author

I'm glad it worked for you. Probably this week I will create a PR.

As you are using sdhc worth another tip, the unmount function was not implemented for fatfs. So I created a PR that you can see here #15712

lucaspeixotot added a commit to lucaspeixotot/zephyr that referenced this issue May 1, 2019
The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes zephyrproject-rtos#15444.

Signed-off-by: Lucas Peixoto <[email protected]>
@Pathak94
Copy link

Pathak94 commented May 2, 2019

Noted! Thanks.

Pathak94 pushed a commit to Pathak94/zephyr that referenced this issue Jun 4, 2019
The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes zephyrproject-rtos#15444.

Signed-off-by: Lucas Peixoto <[email protected]>
lucaspeixotot added a commit to edgebr/zephyr that referenced this issue Jun 7, 2019
The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes zephyrproject-rtos#15444.

Signed-off-by: Lucas Peixoto <[email protected]>
nashif pushed a commit to lucaspeixotot/zephyr that referenced this issue Jun 18, 2019
The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes zephyrproject-rtos#15444.

Signed-off-by: Lucas Peixoto <[email protected]>
lucaspeixotot added a commit to edgebr/zephyr that referenced this issue Jul 18, 2019
The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes zephyrproject-rtos#15444.

Signed-off-by: Lucas Peixoto <[email protected]>
pabigot pushed a commit to pabigot/zephyr that referenced this issue Jul 22, 2019
The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes zephyrproject-rtos#15444.

Signed-off-by: Lucas Peixoto <[email protected]>
Signed-off-by: Peter A. Bigot <[email protected]>
galak pushed a commit that referenced this issue Aug 1, 2019
The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes #15444.

Signed-off-by: Lucas Peixoto <[email protected]>
Signed-off-by: Peter A. Bigot <[email protected]>
pabigot pushed a commit to pabigot/zephyr that referenced this issue Aug 1, 2019
The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes zephyrproject-rtos#15444.

Signed-off-by: Lucas Peixoto <[email protected]>
Signed-off-by: Peter A. Bigot <[email protected]>
lucaspeixotot added a commit to ayna-tech/zephyr that referenced this issue Aug 1, 2019
The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes zephyrproject-rtos#15444.

Signed-off-by: Lucas Peixoto <[email protected]>
LeiW000 pushed a commit to LeiW000/zephyr that referenced this issue Sep 2, 2019
The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes zephyrproject-rtos#15444.

Signed-off-by: Lucas Peixoto <[email protected]>
Signed-off-by: Peter A. Bigot <[email protected]>
nashif pushed a commit that referenced this issue Sep 25, 2019
The sdhc_cmd_r1_raw() function doesn't take into account the existence
of commands with data response. Because of this, some datas were being
lost.

The commands that return a r1 response and a data are: SDHC_SEND_CSD,
SDHC_SEND_CID, SDHC_READ_SINGLE_BLOCK, SDHC_READ_MULTIPLE_BLOCK,
SDHC_WRITE_BLOCK, SDHC_WRITE_MULTIPLE_BLOCK.

In order to solve this, was juts necessary skip the byte discard when
the command is one of these.

This problem was affecting, for example, the sdhc initialization. The
token returned from SDHC_SEND_CSD was being lost and the initialization
was broken.

Fixes #15444.

Signed-off-by: Lucas Peixoto <[email protected]>
Signed-off-by: Peter A. Bigot <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Disk Access bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
3 participants