Problem after authentication

Hi Josh, thank you for your response
I'm using ATMega128, and ported the sources form reference code.
I tried using SPI and Special direct mode, I can read UID code correctly and I followed steps on sloa214 by logic analyzer till step 23 and all are just like the figures in the document.

I think there should be some error when it going to run crypto1_mutual_1() for decryption, maybe something is wrong with AVR that cannot run the code

Hi Behnam,

Are you calling the function from a source code file in your system or a pre-compiled library provided by TI?

Hi Ralph

I added source codes from system, a set of files received by other member of team previously

Okay,

Can you take and send us a Logic State Analyzer capture of the communication lines then? We need to see all of these lines: MISO/MOSI/SS/SPI CLK (SPI lines), IRQ, and I/O_2, I/O_3, and I/O_5 (SDM lines). Something like in Figures 7 through 12 of the document.

I believe the timings for SDM are still fairly tight (but much better than DM0 still), so could be an issue there.

Hi Dear Ralph, thank you for your response

Here it is the shots from Logic State Analyzer, The SS signal is missed but I'm sure about it

Hi Behnam,

These may be fine and tell us enough, we'll give them a look through, but if you could send the whole .logicdata that'd be even better! You can attach it on the thread, or if you want it to be private then send me a friend request and you can send it to me in a private message.

Dear Ralph

Here it is the log file, please find the last transmission cycles on a long delay after DM1_Receive process (Because of the delay for debug texts on UART)

www.dropbox.com/.../16 MHz, 32 M Samples.logicdata

thanks 

Behnam

Hi,
Any news Dear Ralph?

Hi Behnam,

Sorry for the delay.

We looked over your logic capture and one thing I noticed is that the SS line is missing from it. Why is that the case? You are using SS in your system right?

If you look at the sloa214 document as a reference for the following comments:

It seems that you are breaking around step 20 on Figure 12 which is exiting DM1 and servicing the IRQ. One of the key components of this is Step 21 which is pulling the SS line high.

Do you have any interrupts service routines running to handle the IRQ? Are you polling for it? In general, how are you handling the IRQ interrupt on your system?

That seems to be the root cause as everything else on the capture so far as looked okay beyond the question of the missing SS line from the capture.

Thank you dear Ralph

I cant find any "Step 20" in codes, we handle IRQ just like reference code in the Mifare_DM1_Recieve() when it see the RIsing Edge and Break the while() loop.

I checked the code, the delay is caused by the message we send on UART after the break to check step 19, does it matter? 

We receive the data truly, the CheckParity(auth1_response, 4) in Crypto1_mifare.c  also goes right until the crypto1_mutual_1(psMifareCipher, uid, tag_challange) when the atmega16 stops or resets.

I think the problem is in encryption routin, am I wrong?

Thank you

Behnam

And here it is the Logic Analyzer data including the SS pin, and removed delays:
www.dropbox.com/.../16 MHz, 32 M Samples [21].logicdata

Thank you so much
Behnam

Hi Behnam,

The step 20 I referred to was from the App Note: www.ti.com/.../sloa214.pdf

I will check the LSA shots shortly.

You are not using a .lib for the encryption API's right? You are instead using the source files provided by TI after applying for access to the source code, correct?

Hi Ralph

Thank you,Yes, we use source codes provided by TI. Is any .lib file to use as API for encryption that work with any compiler?

Thank you so much Dear Ralph

we checked entering the crypto process previously, I'm sure it goes inside the crypto1_mutual_1() function and then micro restarts!

So I think we need to work on crypto process  to check compatibility  with other compilers.

Thank you for your helps, I will update the post if we conquer the problem.

Best Regards

Behnam