How to go through wolfTPM2_Init with gdb about wolftpm HOT 7 CLOSED

Hi @kwmartin ,

If you build wolfTPM with ./configure --disable-shared --enable-debug it will statically link the executables and you can use gdb. Otherwise the executables are in src/.libs and the generated scripts setup the runtime libraries dependencies.

Thanks,
David Garske, wolfSSL

from wolftpm.

This has helped a lot. I have some issues I need to work through, but I now have gdb running through examples/native/native_test.c. Thank you. If you have time, to answer another question? Since I'm doing software channel select, I need to bring in a gpio_access library (not a problem as I can use LIBS="gpio_access" when configuring, but I also need to initialize the GPIOs at startup. It seems to me the best place is TPM2_Init_ex() in tpm2.c? Would you agree with this? Finally, I'm curious how the userCtx is intended to be used. Thank you for your help.

from wolftpm.

Hi @kwmartin ,

I recommend doing it in your custom HAL callback. The HAL IO callback and userCtx is setup on the call to TPM2_Init_ex. This will provide you the opportunity to do first time initializations and keep track of it.

Thanks,
David Garske, wolfSSL

from wolftpm.

Did a config with:
./configure --disable-shared --enable-debug --enable-infineon CFLAGS="-O0 -g3 $CFLAGS" LIBS="-lwiringPi -lgpio_access"
I called setupGpios_() (my setup function) from TPM2_Init_ex() and verified that GPIOs are working. I'm using a device tree overlay with one chip select that is not on the PI headers. In TPM2_IoCb_Linux_SPI() of tpn_io_linux.c(), I'm toggling the CS using wiringPi's digitalWrite(CS0N, LOW); and digitalWrite(CS0N, HIGH); and have verified using gdb and a voltmeter that this is working. I found TPM2_SPI_DEV was wrong
(gdb) macro expand TPM2_SPI_DEV
expands to: "/dev/spidev0.""1"
(gdb)
so (for now), I changed opening spidev to "/dev/spidev0.0" which is working. I took off my hat, jumped MISO to MOSI and using gdb in TPM2_IoCb_Linux_SPI() after the ioctl called verified my spi is working.
(gdb) x/5xb spi.tx_buf
0xffffffff7928: 0x80 0xd4 0x00 0x00 0x00
(gdb) x/5xb spi.rx_buf
0xffffffff7970: 0x80 0xd4 0x00 0x00 0x00

All is good except: Besides the SPI interface, the only other pin connected to the SLB9670 is the reset pin (active low). The very minimal data sheet for the the SLB9670 states this has a weak pull up. I also configured my GPI as an input with a pull up. This pin only goes to the the PI GPIO 4, no where else. With the board removed, I verified it is a high impedance input and the the configuring pull_up, pull_down, and pull_off work as expected. However, with the board connected and breaking in TPM2_IoCb_Linux_SPI() just before the size = ioctl(spiDev, SPI_IOC_MESSAGE(1), &spi); call (now line 287 of tpm_io_linux.c with my changes) and I measured the reset input (pin 17 of the SLB9670) on one board, I read 0.88V and on a second board 1.51V. Again, this pin is only connected to the PI GPIO configured as input with a pull up. If I get rid of the pull-up, the voltage is close to 0V. When I measure the impedance of the pin to ground or 3.3V of a disconnected board, it's over 1Mohm. I also verified connectivity and no shorts of an unpopulated board. The SLB9670 interrupt output is a no-connect. I can't figure why the reset input is sinking current; it's supposed to be an input. It seems to me the SLB9670s are either broken or doing something "funny" with this pin to pull it low. When I connected a 550 ohm resistor between the pin and 3.3V, the voltage moved up by 0.5V indicating 1mA is being sinked low and the impedance is close to 2K

Any ideas? I'm at an impasse.

from wolftpm.

Hi @kwmartin ,

You are very close! It sounds like that GPIO 4 is being driven by something. I would recommend not attaching the TPM reset line. Let the internal pull up keep it out of reset. Most implementations don't use the reset or interrupt lines... they are not required.

Note the /dev/spidev0.0 means it will assert the CS0. See device tree entry "cs-gpios".

Thanks,
David Garske, wolfSSL

from wolftpm.

Hi @kwmartin ,

Were you able to get things working okay? Should we consider this issue solved?

Thanks,
David Garske, wolfSSL

from wolftpm.

David, thanks for the help. Everything on my board is working excecpt the 9670. I have checked connections using an unconnected board and an impedance meter and the connections appear correct, but I can't get the SPI communicating to the 9670. When connecting MOSI to MISO directly, the SPI looks fine. I'm guessing the 9670's are dead, but until I put some new boards out, this is only a guess. Because I'm at an impasse, I would guess the issue should be closed. Thanks again for your help.

from wolftpm.