How to go through wolfTPM2_Init with gdb

[kwmartin]

Background, I have an RPi hat with an RFID reader (NXP PN7150), an RTC (Maxim DS3232), a number of connectors for attaching spi and i2c mini boards (2 spi, 3 i2c0, and an Infineon SLB 9670. The spi is configured to use software chip select, as the spi is not just for the 9670, but also for the two off-board spis. The last thing I need to check is the 9670. My gpio setup is (SCK: GPIO11, MOSI: GPIO10, MISO: GPIO9, CSN: GPIO14). I'm trying to figure out how to connect with gdb to see if the spi is working correctly with the 9670. The examples directory have bash scripts but don't seem to have executables. Could someone suggest a good entry point to be able set a break point in wolfTPM2_Init(). I have seen that tpm_io_st.c uses software chip select, and I'm hoping to do something similar but using spidev and ioctl(SPIfd, SPI_IOC_MESSAGE(1), &xfer). Any suggestion(s) on how to get started are appreciated. Thank you.

[dgarske]

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

[kwmartin]

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.

[dgarske]

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

[kwmartin]

Did a config with: ./configure --disable-shared --enable-debug --enable-infineon CFLAGS="-O0 -g3 $CFLAGS" LIBS="-lwiringPi -lgpioaccess" 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.

[dgarske]

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

[dgarske]

Hi @kwmartin ,

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

Thanks, David Garske, wolfSSL

[kwmartin]

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.