AK-SDFS-UART not responding

Support
#1

Hello,

I am having some difficulties getting the AK-SDFS-UART board to work. I am not using an Arduino, so i haven’t imported your libraries but i feel like what i am doing is simple enough. I also just have some general questions that don’t seem to be covered (or expressly stated) in the documentation.

  1. The default baud rate is 9600 8N1 correct? there is nothing non-standard about the serial port?

  2. When sending commands that are only checking status, e.g. Check Card Presence Command, do i need to include File handle/opt, data length, and data? do i make them all zero? Do i send data length of zero and exclude data, jumping right to the CRC?

3)When calculating the CRC using the function you provided, do i put 0x0000 in for partial when calculating a new CRC?

Here is what i have tried to do specifically:
I first tried to create a file; no response from the module, no file on the 32GB SD card.

I then removed the SD card and asked if there was an SD card present.
I send 0x41, 0x4B, 0x0C, 0x00, 0x00, 0x00, 0x9D, 0x15
I verified that is what i have sent what i intended to send with a Saleae logic analyzer. (see attached image)

37%20PM
37%20PM2606×1486 303 KB

I even tried including 0x00 as data, and with all zeros excluded (so just preamble command and CRC16)
I received no response from the module.

I even tried sending a bunch of garbage over serial, just random hex numbers, and received no error messages.

For all of the above situations i have seen the PROT light (i assume this should be PORT?) flicker. I don’t know if this is hardware based or if the MCU is responsible for flickering the light, so i’m not sure at what level it is receiving data.

I have Arduino compatible boards i may try next, but i feel like what i have tried to do so far is so simple that i should at least be seeing error responses instead of silence.

Thank you

#2

Hi @Ezekiel,

That is correct.

Yes. Preamble, command, file handle/opt, data length and CRC must be sent even if they are zero. Data should not be sent if the length is 0 (i.e. no data).

Yes. The partial parameter is only used when you do CRC calculations in several steps. In that case you should set partial as the last CRC value you have calculated.

The board won’t answer for invalid commands.

I think it meant to be “protocol” as in communication activity.

The MCU makes the LED blink when it receives data, so the MCU is alive and parsing whatever you are sending.

Here is a complete command that opens a file: AK-SDFS-UART doesn't work

The command was used to diagnose a problem another user was having. You can use that to compare the data output of your program with what the board expects.

Provided that the CRC is correct, I might suspect that maybe there is a problem with endianess? I would swap the CRC bytes and give it a try.

But the best thing to do in this case is to check with the linked packet example to compare your output with a given known command.

Ivan.

#3

Thank you for your quick reply.
I saw the forum post that you linked, but i had only gotten to the point where the poster said he had it working. If i had continued reading i would have found your correction to the error in the documentation that had confused me greatly. I was able to get it working last night, after a coworker fiddled with it for a bit.
Might i suggest, when you update the documentation with the error on the Endianness of the data length variable, that you explicitly state that the data length and CRC are little endian and explicitly state that the module will not respond to any message and only to correctly formatted messages.

Thank you
Ezekiel Hadley

#4

Hi @Ezekiel,

I’m glad you got it working.

I’ll check if we can add to the manual that the module doesn’t answer to invalid packets. For endianess there is:

image
image1161×212 13.7 KB