ATSAM4S & HSMCI & Assembly = Stuck

Log in or register to post comments
Go To Last Post
4 posts / 0 new
Author
Message
FEx
FEx's picture
Level: Rookie
Joined: Wed. Jul 18, 2018
Posts: 34 View posts
#1
Posted by FEx: Mon. Feb 28, 2022 - 07:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Community,

 

the Title says (almost) all - ´m quite Stuck concerning using the HSMCI-Interface with Assembly in order to get Access to a HCSD-Card.

 

If i may add - i´m not totally unfamiliar with handling of SD-Cards, since a lot of self-written SD-ASM-Code has been involved in

my AVR and X51-Projects (for the past 25 Years) and it works there quite happy, but the HSMCI-Interface vs SPI-Access is of course quite different.

 

 

Well, after some struggeling regarding a proper Port Setup/Peripheral assigment/Clock speed i think that the interfacing to the card does work at all-

 

on a very basic level. Far below the 400 KHZ-Limit for initialisation. After sending 74 Clock Cycles in 1 Bit-Mode and after CMD0 (without response)

i send a CMD8 with Argument 0x1AA and the card responses with 0x1AA. So far, so good. Although the card normally responses on CMD0 with 0X01

on my other platforms, but here it doesn´t happen.

 

The next command is CMD59 with an 48 Bit response in order to turn CRC checking off (of course unnecessary on this platform, but just "for the sake of it"),

but the card also responses with 0x1AA and i´m not sure if this would be correct, because i have maximum difficulties to switch my brain from 8 to 32 Bits

when it comes to the response at all.

 

 

The 0x1AA-Response of CMD8 is understandable to me (0x1=Voltage accepted, 0xaa=Command mirror), but the next Command, which throws the same response,

couldn´t let me decide if the command response is ok or not. At the moment í am "feeling" that the last command (CMD8) hasn´t been successfully terminated - for whatever reason.

Before each submitted command i fill of course the Argument register with the proper values, check XFRDONE in HSMCI_SR for the command register being "free" and after

submitting the command register i also check CMDRDY in HSMCI_SR.

 

In 8 Bit SPI Mode i would read consecutive one byte after another from the Response and, in this case, at the third byte i would get "0x01", which indicates

an idle state=OK, next command. But at 32 Bits (or more) i would have to cut up those 32 Bits in 4*8 Bit Chunks and check if any of these chunks contain a valid response.

 

And here i don´t know if this would be a correct method or not, because i am unaware if a correct response would be rather "0x00000001" in the resposne register or the above

mentioned method. I´m also unaware which role play the additional response registers of the HSMCI-Interface - if this is more a buffer where the contents move from Response

Register 4 up to Response Register 1 for each consecutive read of Response Register 1 - or not....

 

Any help is very appreciated !

 

Kind regards !

Tags:

Atmel SMART ARM-based MCUs and MPUs, Atmel Cortex-M MCUs
Last Edited: Mon. Feb 28, 2022 - 07:08 AM
Top
FEx
FEx's picture
Level: Rookie
Joined: Wed. Jul 18, 2018
Posts: 34 View posts
Posted by FEx: Thu. Mar 3, 2022 - 01:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, got further with my assumptions.

 

I´ve really thought at first that the HSMCI-Interface was covering some sort of SPI-Mode (because of the fact that you have also to send 74 CLKs in order to initialize the card, which is usually the Sequence for switching SD-Cards to SPI-Mode), and so i was assuming that the card would deliver its response Data in the same format as on other Platforms in SPI Mode - which is wrong, since the Card is running in native SD Mode. I always thought that the Native SD mode wasn´t "open" to the End-Consumer.

 

Because of that i was quite confused about how to handle the responses.

 

Well, up to this point i´ve got trough Cmd0, CMD8,ACMD41 (with the difference to SPI that CMD41 needs to the 0x40000000 argument additional Bits have to be set in order to get the Card into Busy State in Bit 31 of the response, so it responds on ACMD41 with 0xC0......), CMD2; CMD3 and CMD7 in a loop until i get a (anded) 0x700 Response, CMD9 and then CMD16 in order to set the block lenght.

 

But then CMD17 also confuses me, since i´ve check the response (as learned from SPI-Mode, wait for a 0xFE Data start token) and this is where i get stuck again. Idk if the HSMCI-Interface checks for this response by itself, because the manually read out response is identical to the last response of the SD Init routine. Not checking for this response but for HSMCI_SR Bit 1 = RXRDY and reading out HSMCI_RDR in a loop with HSCMR_SR gives also the last SD init response....

 

Kind regards

 

 

Top
FEx
FEx's picture
Level: Rookie
Joined: Wed. Jul 18, 2018
Posts: 34 View posts
Posted by FEx: Fri. Mar 4, 2022 - 07:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, again got a bit futher.

 

Mainly the Reason why the Card wouldn´t react to CMD17 at all with an invalid response was that the RCA (generated by CMD3 ,needed by some of the following Commands as an Argument) was Zero/invalid in the time of the first call, so i had to redo CMD3 until long the upper bytes of the response, anded with 0xffff0000, weren´t zero.

 

At the moment the Card reacts to CMD17 with an ANDed 0x00000900-Response, but doesn´t always go further when trying to readout the Databuffer MANUALLY- not in PDC-Mode - by checking for RXRDY Bit 1 and reading out HSMCI_RDR in a loop until the 512 Bytes of a single block have been read out - interestingly it depends on the Baud rate on which the UART (for debugging purposes, putting the contents of HSMCR-RDR straigt to the terminal) operates (?) - slow speeds like 38400 a good response, fast speeds - no Data flow at all, although the card currently already operates with a Clock divider of 255 @ 60 MHz

 

Furthermore the card doesn´t  seem to accept BLOCK-Addresses which are easily accepted in SPI-Mode; it responses with the 0x900, but doesn´t go further - for whatever reason. Maybe the Clock speed with which the HSMCI-Interface was configured is far below an accepted range, but that would be new to me that slow clock speeds could be an issue. Timeouts?

 

 

Edit - well, the direct response to CMD17 which is anded through 0x900 is in Fact 13 7F FF FF. If i would be in SPI Mode and would take 0x13 from the left, it would be at least an address error plus "Erase reset" and "in idle state", thus not proceeding - but i cannot figure out why, because the Blocklenght has been set previously and the address if perfectly in range and aligned (even its not necessary in Bloc mode) . Its for me extreme complicated to figure it out how the 48 Bit response is aligned in the Response Register. Maybe i missed something in the Datasheet?

 

 

 

Last Edited: Fri. Mar 4, 2022 - 11:46 AM
Top
FEx
FEx's picture
Level: Rookie
Joined: Wed. Jul 18, 2018
Posts: 34 View posts
Posted by FEx: Wed. Mar 9, 2022 - 08:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Works by now in 4 Channel-Mode and maximum speed. In fact it were certain points where the card responded with Data and which -had- to be read out trough an initialisation command - where i tought that can be overrided (wasn´t necessary to do that in SPI mode either).

 

 

 

 

 

Top