GPIO Input (P00.x) Read differently in RUN and Standby mode.

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

cross mob
lock attach
Attachments are accessible only for community members.
Liyung
Level 2
Level 2
First like received 10 replies posted 5 sign-ins

GPIO Input (P00.x) Read differently in RUN and Standby mode.

I used TC397 on both Aurix evaluation board and TFT.

The problem is shown in details in the attachement.

But simply to say, the GPIO input can be read by SCR correctly when Tricore is in RUN mode.

But when Tricore goes to Standby mode, SCR read the Pins always 1, although I connected the pins with GND. 

The pin is set Tristate before entering Standby, and the SCR initialize the pin as no pull. The pin is handed over from tricore to SCR by writing 1 in P33_PCSR and  P34_PCSR register during tricore startup.

Thanks.

29 Replies
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Hi,

do you provide a separate Standby Power Supply (V_EVRSB)? If not, Port domain P33.x / P34.x would have simply no power, which would explain your issue.

Best regards,

TBencher

0 Likes

Hello,

thank you for pointing out the potential casue. 

As I currently don't have multimeter, but first I can see that in standby mode, the VEVRSB is still supplied by TLF35584QV according to ApplicationKit TFT TC3X7 manual. VEVRSB is always supplied by TLF35584QV .

Liyung_0-1649931402589.png

If I triggered Tricore to standby by:

Liyung_1-1649931583495.png

TLF35584QV should not be affected. Let me know if there is any concern to this TFT board. 

Liyung

 

0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Hi,

that is very good. To work with the LDO_Stby, which is actually our Standby Power Supply (V_EVRSB), you need to enable it for NORMAL state via SPI- command from the TC. If the TLF changes from NORMAL-State to STANDBY state, the last configured ON or OFF state of the LDO_Stby will be preserved. Hence, I think you just need to enable the LDO_Stby for NORMAL state and your problem will be solved.

Best regards,

TBencher

0 Likes

Hello,

nice that you pointed out this issue. I am going to set up SPI to configure TLF35584. Becasue I am using AUTOSAR basic software stack, I need more details about the SPI configuration. Could you provide the configuration/parameters for SPI communication to TLF35584 chip or example so that TC can communicate with TLF35584 accordingly?

0 Likes
Liyung
Level 2
Level 2
First like received 10 replies posted 5 sign-ins

I found it:

AP32342 - AURIX TC3xx: Testing and servicing the TLF35584. I will try next week and let you know! 

https://community.infineon.com/t5/Power-Management-ICs/Example-Code-for-TLF35584-and-TC37XX-SPI-comm...

Have a nice weekend!

0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Hi,

that is perfect! Have a nice weekend as well.

Best regards,

TBencher

0 Likes
Liyung
Level 2
Level 2
First like received 10 replies posted 5 sign-ins

Hello, 

as long as my tricore code did not have any QSPI communication (QSPI2) with TLF35584, how is the state in TLF35584 looks like when power up? 

According to manual, from my understanding, the LDO_Stby should be selected as ON by default and the state is always in INIT as long as there is no QSPI communication to TLF33584 after powering up. (currently I did not try to configure TLF35584 to NORMAL state or STANDBY state, so I think it is always in INIT state)

Liyung_1-1650469941900.png

 

If I am not wrong, 

Liyung_0-1650469679604.png

 

0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Hi,

yes that is true.
If you didn't have any SPI traffic so far, LDO_Stby should be switched ON.
Did you measure the LDO_Stby voltage yet?

Regards,

TBencher

0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

You should also observe SPI channel whether there is any traffic... Maybe your BSP is already servicing the TLF.

0 Likes

Hello, 

What do you mean by BSP? 

I am using Autosar stack to configure QSPI and Port behavior. I did not configure any QSPI2.

0 Likes

Just wanted to say that the SW for this TFT kit may have already communication to the TLF.

0 Likes

Hello,

I doubt we refer different SW. I flash our AUTOSAR-like software and did not see any QSPI2 in my software. Or what kind of SW do you mean?

0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Please also look in the schematics of the TFT kit. It is very likely that your input pins are already in use by peripherals. The TFT kit does not have so many free pins. Please check this also.

0 Likes

Hello,

I know that

P14.2 QSPI2 Slave Select Output 1 for SCS of TLF35584
(P15.8) or P15.3 QSPI2 Master Clock Output for SCL of TLF35584 (conflict to HB5_LS_CTRL_uC)
P15.6 QSPI2 Master Transmit Output for SDI of TLF35584
P15.7 QSPI2 Master Receive Input B for SDO from TLF35584

already connected to TC. So I don't need to connected anything to TLF.

0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Surprise, surprise... I have the same kit here... I will just do a little program and look what happens on the TLF site....

 

Best regards,

TBencher

TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Hi again.

I've just played a little bit around. With SLEEP Mode everything went fine. With STANDBY Mode unfortunately the board does not recover from it. Just forgot to define how it should be waked up again. Bad things happen 😉

Best regards,

TBencher

0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Ok. It is working again... Meanwhile I have measured the standby voltage, which is on.

0 Likes

Hello, 

that is matching our expectation. So bascially, LDO_Stby is always on (TLF always in INIT, reflect my case, without any QSPI2 communication).

0 Likes
Liyung
Level 2
Level 2
First like received 10 replies posted 5 sign-ins

Hello,

is there any other factor that could cause the always-reading-1 in GPIO input during standby mode, except LDO_Stby always ON.

0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Hi,

maybe this is the solution:

"SCR PORT module shares a part of the PORT (P33.0 - P33.7, P33.9 - P33.15 and P34.1) domain with the main port system which may be kept active during Standby mode. The SCR ports are supplied by VDDPD and VEVRSB standby supply. The control to these pins need to be allocated explicitly to the SCR via port configuration Pxx_PCSR register. Unused wake-up pins may be configured as tristate in Standby Mode."

As for my understanding, the XC800 which is actually our Standby Controller, has then access to these pins. So you should poll them from this embedded Microcontroller.

 

Best regards,

TBencher

0 Likes

[updated]

Hello, 

I was aware the handover topic. Now I doubt that my use case could have issue. The sequence is illustrate as the following:

Liyung_1-1650889457384.png

 

 

Li-Yung

0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Hi,

you need to configure your shared ports to be controlled by the SCR, otherwise they would be tristate.
Please compare bit TRISTREQ where you can do it.

"TRISTREQ Tristate enableThis bit decides whether pads behave as inputs with weak pull-up or tristate on reset assertion/de-assertion or Standby- Wake-up transition. After supply ramp-up or LVD reset, TRISTREQ = ! HWCFG6.

0B No request to switch the input pad state of all the pads to tristate from pull-up (default reset state)
1
B Pad domain in tristate. VGATE1P pull up remains active if VEXT available and EVRC SMPS selected.

 

Please also consider measures as described in UM while entering Standby Mode depending on your supply setup.

 

Best regards,

TBencher

0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Hi,

please look also into your Port configuration.

"Pin Controller Select Register

Port n Pin Controller Select Register

This register has different functionality in each port:

  • In Ports shared with the standby controller (SCR) it selects if the SCR or the Tricore system control data and control functions of these port lines.

 

Register: PCSR

Field: SELx: Output Select for Pin x

Depending on the port this bit enables or disables Tricore/SCR control, the EVADC pull control for Pull Down Diagnostics (PDD) / Multiplexer Diagnostics (MD) feature, SMU override or alternate/fast Ethernet output.

 

Best regards,

TBencher

0 Likes
Liyung
Level 2
Level 2
First like received 10 replies posted 5 sign-ins

Hello,

I did configure as you suggestion, before going to Standby mode, the pins are handed over to SCR and tristate is set up:

Liyung_0-1650894148602.png

 

0 Likes
Liyung
Level 2
Level 2
First like received 10 replies posted 5 sign-ins

Hello, 

some interesting foud,  P33_PCSR was not changed as intended. 

Liyung_1-1650895127352.png

 

0 Likes
Liyung
Level 2
Level 2
First like received 10 replies posted 5 sign-ins

but before standby, it is corret:

Liyung_2-1650895230199.png

 

0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Hi,

please try in PMS_PMSWCR5.U to set TRISTREQ to 0.

 

Best regards,

TBencher

0 Likes

Hello, 

weird, I also tried this config, and the outcome is still same. Is there any GPIO config that I missed in SCR code ? 

If I am not wrong, the following 2 lines are enough when running SCR code.

SCR_IO_PAGE = 1;
SCR_P00_IOCR4 = 0x00;

Liyung_0-1650897822198.png

 

0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked

Hi,

this configuration seems to be ok for P33.4.
I think it would be much easier to find your problem if you would drop your source code
to info@tbench-solutions.com . There we can see the whole configuration. 

 

Best regards,

TBencher

0 Likes