Weird GPIO behavior in CY_U3P_IO_MATRIX_LPP_DEFAULT mode after boot from SPI

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
SeKa_293236
Level 1
Level 1
First reply posted First question asked First like given

Hi,

I observe a strange behavior of GPIO[51] pin in the following scenario:

PMODE pins set for SPI boot and lppMode is set to CY_U3P_IO_MATRIX_LPP_DEFAULT and GPIO[51] is configured as simple GPIO and set to output logic 1.

In such particular case GPIO[51] output is in high-impedance state instead of expected logic 1. Overriding the pin does not help. I also checked the state of I2S, UART and SPI hardware blocks via appropriate registers -- all these blocks are disabled.

However, if PMODE pins are set for USB boot or I2C boot, same firmware works just fine -- GPIO[51] outputs logic 1. Also if lppMode is set to something other then CY_U3P_IO_MATRIX_LPP_DEFAULT, again GPIO[51] is working as expected now even for SPI boot.

And the most weird thing is that if in addition to GPIO[51] another GPIO -- GPIO[57] -- is also configured as simple GPIO, than GPIO[51] suddenly starts working properly (outputs logic 1) in that bad scenario described above.

It seems like booting from SPI lefts something in IO_MATRIX configuration that prevents GPIO[51] from working as Simple GPIO when lppMode is CY_U3P_IO_MATRIX_LPP_DEFAULT. Like that pin is still reserved for some hardware block. Configuring separate GPIO[57] as Simple GPIO resolves IO_MATRIX problems, which is very strange.

 

Do you have an explanation for such a weird behavior? It looks like a bug in Cypress firmware library related to SPI boot and CY_U3P_IO_MATRIX_LPP_DEFAULT.

Thank you!

-- 

Sergey.

0 Likes
4 Replies
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi Sergey,

1.Could you let us know what is the io_cfg.useI2S set to when the issue occurs. Does changing this value solve the issue?
2.What is io_cfg.isDQ32Bit set to?
3.Which all LPP peripherals are used for the application?
4.Is superspeed explorer kit being used?

Best Regards,
AliAsgar

0 Likes

The configuration is:

io_cfg.isDQ32Bit = CyTrue;
io_cfg.s0Mode = CY_U3P_SPORT_INACTIVE;
io_cfg.s1Mode = CY_U3P_SPORT_INACTIVE;
io_cfg.useUart = CyFalse;
io_cfg.useI2C = CyFalse;
io_cfg.useI2S = CyFalse;
io_cfg.useSpi = CyFalse;
io_cfg.lppMode = CY_U3P_IO_MATRIX_LPP_DEFAULT;

io_cfg.gpioSimpleEn[0] = 0;
io_cfg.gpioSimpleEn[1] = FX3_GPIO_TO_HIFLAG(51);
io_cfg.gpioComplexEn[0] = 0;
io_cfg.gpioComplexEn[1] = 0;

-------------

So io_cfg.useI2S = CyFalse, io_cfg.isDQ32Bit = CyTrue. That is why I need to use CY_U3P_IO_MATRIX_LPP_DEFAULT as this is the only allowed option when io_cfg.isDQ32Bit == CyTrue. I've also tried with io_cfg.isDQ32Bit = CyFalse -- it does not make a difference in weird GPIO behavior.

The problem only occurs when boot from SPI is selected. I'm not able to select SPI boot on Explorer Board. When PMODE is set to USB or I2C boot everything works fine.

Replacing the line io_cfg.gpioSimpleEn[1] = FX3_GPIO_TO_HIFLAG(51); with 

io_cfg.gpioSimpleEn[1] = FX3_GPIO_TO_HIFLAG(51) | FX3_GPIO_TO_HIFLAG(57);

magically solves the problem.

I've also checked with OpenOCD debugger the states of I2S, SPI and UART blocks in appropriate registers. All these blocks are disabled as expected.

0 Likes
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi Sergey,

Could you share the code snippet where GPIO 51 initialization is done?
Meanwhile we are checking if we can reproduce the issue at our end.

Best Regards,
AliAsgar

0 Likes
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi Sergey,

We do not see this issue at our end. Could you provide a code snippet of the GPIO 51 initialization.

Best Regards,
AliAsgar

0 Likes