[Cryptech Core] MKM access from FPGA

Joachim Strömbergson joachim at secworks.se
Wed May 25 06:04:46 UTC 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Paul Selkirk wrote:
> tl;dr: I've been trying to validate Joachim's mkmif core, with
> limited success. As in, I read 0xffffffff from all locations.

> What I see is this:
> 
> Trying to adjust the clockspeed. write  020a [ 00 00 00 20 ] read
> 020a [ 00 00 00 20 ] Trying to init to the memory in continuous
> mode. write  0208 [ 00 00 00 04 ] read   0209 [ 00 00 00 02 ] read
> 0209 [ 00 00 00 03 ] Trying to write 0xdeadbeef to the memory and
> then read back. write  0210 [ 00 00 00 00 ] write  0220 [ de ad be ef
> ] write  0208 [ 00 00 00 02 ] read   0209 [ 00 00 00 02 ] read   0209
> [ 00 00 00 03 ] write  0210 [ 00 00 00 00 ] write  0208 [ 00 00 00 01
> ] read   0209 [ 00 00 00 00 ] read   0209 [ 00 00 00 03 ] read   0209
> [ 00 00 00 03 ] read   0220 [ ff ff ff ff ] read ffffffff, expected
> deadbeef

The command sequence looks correct. You could try and lower the SPI
clock a lot more (0xff) and see if this effects the number of status
reads you have to do before getting ready bit set. Then we know that at
least the FSMs are running as they should.

What is probably needed is to use an oscilloscope and logic analyzer to
look at what the Microchip memory receives during this. If the CS_N is
high all the time, if the di and do signals and the clock is correct.

Looking at the data input pin (spi_do) if its stuck at one would be
pretty revealing.

The core doesn't really know that it has contact with the memory. It
simply pulls cs_n, generates the clock and pushed bits out in cadence
with the clock. And samples the data input pin at the same time.


> I *think* I originally mixed up miso and mosi in the .ucf file, so I 
> corrected that, but with no change in output.

The inputs and outputs are confusing. I followed the convention used by
the Microchip memory. And from its perspective so/do is the output. But
it really makes the naming at the other end pretty ugly.


> As I understand it, Joachim developed this core on the Novena,
> talking directly to a 23K640 memory chip on a breadboard (not through
> a MC74AC244DW line driver/switch).

Yes. I only had four pins out from Fredriks noise board and used them to
connect directly to the memory on a breadboard. No line driver/switch
was used in between.


> I'm sure I'm missing something simple and obvious (along the lines
> of miso/mosi or a jumper), but I can't see what it is.

Do you have a logic analyzer and/or scope? Connecting it before the
switch and then after should establish where the problem is.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJXRUB+AAoJEF3cfFQkIuyND9MQAIi0HBlMTxUdYgKBy7IyI6sW
fAUKZF8f6guQYBNVRdBOKZlrYBD+q3M153lZfBzsXyKPkZJ0z/bL3k1keLUBolFn
xVKnpeigrlqY8D5xSF8I/qjRCr2H0EwupMlZKATGXw2CUNHo5qpuJzKBtVb4U43z
zQ973qdqOi0CxIkkLZ5kIO9LxoJpN+SR0OE4JHscpIdbSsPr9o5zhITkxac/CSLM
ajG0hgDX3EVQ7AFLjifU8G+K0cJImX7NeyymqJlmstCerZAC4opzHd+t7+X9DpD3
fe4zfVwA9BPERiOicNTD6+Dtxefiw/5PkL/kb7nGqsSgbpDDCFyCbjIKlsX44d+m
gb8LIiOJhODXlHbcFiEirgEkDp/7SPSJIMXaafw7FKyscypOBXdMRPIJy7+ZM7jp
pSPbbUUG6e2iJQ+I25m+F5pySVmGBU1GGi3C501CNAjgxhGNyf6i8EdqboaVm5R1
Yz0NkewXWrBwTcJSAqFu7g4e8dWR0YtSC3tu5Ns5HDnutmPUGSdW1b4yLa2vMewh
XANRw/I36KyX0gwcfjM91GFJkvwBKQu6fZ9OS1LITtppznRmF6GIbmIp9ZpK21rV
ZNeeBX31t6B29NHQPk4DNIcxezu4WF7uzOum45CQ93SScQXDWcIdipr/Z+feKaHS
Anjw4KChTzb7KAZcKCCb
=SGH3
-----END PGP SIGNATURE-----


More information about the Core mailing list