AM3352: SD_PSTATE register CLEV latency

Have you properly configured the conf_<module>_<pin> register associated with the pin in question?

For example, mux mode bits [2:0] and input enable bit [5] must be configured properly for this input to be connected to the MMC/SD module.

There is a way to verify the connectivity. The MMC/SD module has a test mode which is controlled by SD_CON[4]. When this bit is set ("1"), the pins are configured as general purpose I/O where the pins are be controlled by the SD_SYSTEST register. So you should be able to set  SD_CON[4], and SD_SYSTEST[1], then read SD_SYSTEST[2] to confirm the MMC/SD controller connectivity to the pin.

Regards,
Paul

Hi Paul,

Yes, I can assess the files which is stored in SD card correctly.

If CMD line is tied to HIGH then CLEV indicates "1".

If CMD line is tied to LOW then CLEV indicates "1".

However, if SW set the GPIO pin depends on the value of CLEV by pollin it while CMD line change its status dynamically then GPIO signal and CMD line signal doesn't match its status.

Please refer to the picture.

DB2 is GPIO siganal which indicates the result of CLEV polling.

I expect that the status of DB2 signal matches with the status of CMD signal.

Therefore, I'm afraid that the CLEV has big latency.

How long is the delay before the CMD line status is reflected in CLEV?

(I know there is possibility that GPIO and SW polling also has latency.)

Thanks and Best regards,

HaTa.

It appears you are operating the interface at 24MHz and the pulse width of CMD can be as short as 41.67ns. You would need to poll CLEV at a frequency greater than 50MHz to detect toggles.

I'm not a software expert, but the polling frequency of CLEV may be very slow relative to toggle rate of the CMD signal when using a high-level OS like Linux. I suspect the polling frequency may be very dependent on where you place the polling routine. I would need to discuss this topic with our software team before understanding the latency of polling.

I'll try to reach out to someone via email and see if I can get some information on this topic, but it may be a few more days before I'm able to discuss this topic with our software team. The building we work in was damaged by a storm a few days ago and it will be a few more days before we are allowed to return to the office. 

There can also be significant latency in toggling a GPIO. This latency has a significant impact on maximum GPIO toggle rate. Several customers have tried to toggle a GPIO fast and found it is limited to a few MHz. I'm fairly certain the maximum GPIO toggle rate has been discussed on this forum in the past so you should be able search and find information on this topic.

Why are you trying to read the state of CMD via CLEV?

Regards,
Paul

Hi Paul,

I'm not a software expert, but the polling frequency of CLEV may be very slow relative to toggle rate of the CMD signal when using a high-level OS like Linux. I suspect the polling frequency may be very dependent on where you place the polling routine. I would need to discuss this topic with our software team before understanding the latency of polling.

I'll try to reach out to someone via email and see if I can get some information on this topic, but it may be a few more days before I'm able to discuss this topic with our software team. The building we work in was damaged by a storm a few days ago and it will be a few more days before we are allowed to return to the office. 

There can also be significant latency in toggling a GPIO. This latency has a significant impact on maximum GPIO toggle rate. Several customers have tried to toggle a GPIO fast and found it is limited to a few MHz. I'm fairly certain the maximum GPIO toggle rate has been discussed on this forum in the past so you should be able search and find information on this topic.

OK, Please confirm it to expert.

Why are you trying to read the state of CMD via CLEV?

Need to know the timing of command transmission completion to manage the system.

Thanks and Best regards,

HaTa.

I ask our software team to review your post and provide some feedback.

They were not clear what you are trying to do, but didn’t expect your approach to work due to unpredictable hardware and software latencies. They suggested you may be able to implement a better solution using a PRU since it is able to do real time IO. The other alternative is to review the functional specification of the MMC/SD module to see if it provides a feature that allows you to know when a command sequence is complete.

Regards,

Paul

Hi Paul,

I'm interested in more details about

> They suggested you may be able to implement a better solution using a PRU since it is able to do real time IO.

How to use PRU to confirm the command completion of MMC/SD?

Thanks and Best regards,

HaTa.