- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 .
If I triggered Tricore to standby by:
TLF35584QV should not be affected. Let me know if there is any concern to this TFT board.
Liyung
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I found it:
AP32342 - AURIX TC3xx: Testing and servicing the TLF35584. I will try next week and let you know!
Have a nice weekend!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
that is perfect! Have a nice weekend as well.
Best regards,
TBencher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
If I am not wrong,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You should also observe SPI channel whether there is any traffic... Maybe your BSP is already servicing the TLF.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
What do you mean by BSP?
I am using Autosar stack to configure QSPI and Port behavior. I did not configure any QSPI2.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just wanted to say that the SW for this TFT kit may have already communication to the TLF.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok. It is working again... Meanwhile I have measured the standby voltage, which is on.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
that is matching our expectation. So bascially, LDO_Stby is always on (TLF always in INIT, reflect my case, without any QSPI2 communication).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
is there any other factor that could cause the always-reading-1 in GPIO input during standby mode, except LDO_Stby always ON.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
[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:
Li-Yung
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 enable: This 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)
1B 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I did configure as you suggestion, before going to Standby mode, the pins are handed over to SCR and tristate is set up:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
some interesting foud, P33_PCSR was not changed as intended.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
but before standby, it is corret:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
please try in PMS_PMSWCR5.U to set TRISTREQ to 0.
Best regards,
TBencher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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