TC332 TLF35584 Fail State Handling

[Teoman]

Hello everyone, I have been trying to debug TC332 Eval Board via winIDEA (iSystem). "SoC Attaching" indication is not disappear because of most probably TLF Fail State Handling. I tried to solve the problem via Debugger Script solution by using QSPI1 connections which is going to TLF, but there is something wrong with my SPI settings  in script. Dou you have any debugger script for TC332 evaluation board? Or how can I solve this TLF switch off problem when I am trying to flash and debug a code?  

[MoD]

Anybody made a change on the board? Per default are the safety features switched off on TLF35584 (pin 22 connected to 5V):

If R508 is not assembled (pin 22 is not 5V) then check R508 or assemble otherwise there is a defect on the board (e.g. too high current on any supply) which result in a switch off of TLF35584.

[Teoman]

Both R508 and R509 are assembled, as far as I know board is not changed by someone. My main problem is that " winIDEA debugger stuck at SoC Attaching which means "VREF is OK and system reset is released. Trying to reach the first SoC level debug registers to enable debug mode. Debug session will tried to be started." " I thought that the reason is TLF switch off. I tried a new  Watchdog disable script before initialization but it didn't work. 

In a conclusion, the registers(R508 R509) assembled and power is on, but Microcontroller is not reachable. the possibility of a defection in the port is high or is there an another solution?? 

Thank you for your attention.   

[MoD]

What happens when you only power the board? The supply will be switched off automatically also? After which time, more or less?

If yes, then the TLF35584 is not switching off the safety feature. In this case the pin 22 of TLF35584 is not high.

If the device only switch off when the debugger make access then any script in the debugger runs which switch off the TLF35584.

[Teoman]

When power on the board, I suppose that automatically switch off because I cannot see a connection with MCU in debugger. 

I also check that pin22(TM) has 5V. I measured via R508. Even there is a 5V, I cannot supply voltage to MCU via TLF. What can be the reason behind of ? I will share mine SPI script in order to  disable the window watchdog and error pin monitoring functionality of the TLF35584 device. Please could you check any problem with my QSPI settings? 

I cannot interpret your last sentence. I cannot check the device is working or not without debugger because I cannot download code to CPU. What do you mean? 

[MoD]

What is the state of the LEDs on board? They are all off or some are on? If they are all off, what happens when you power the board (e.g. LEDs on for very short time, for some ms then off, then on for some ms, then off, then on then completely off)?

[Teoman]

When I supply power(12V) to the board, only D504(RED) LED is in on state  until I disconnect the power. Other LEDs don't change and off state all the time. 

[MoD]

Sure that all other LEDs in off state? D507 and D504 are powered by the same voltage, this means when D504 is on then also D507 (V_UC, green) must be on.

[Teoman]

I share  the picture whem I supply 12 V, only red LED is on state and above LED which is green one D507 is off state at least it looks like 🙂 . Am I see wrong?  

[MoD]

Unique explanation I have for this is that anybody made some changes on the board:

You have a stable V_UC then min. D507 must be on also. The good point of this that there is no issue with the TLF35584. The TLF35584 is not in FAIL state and don't need any script to be executed.

Because the LEDs are not working you must check (measure) all supplies that they are in the expected range. Signal PORST should be high, if not then there is an issue with any supply and the debugger is never able to connect. If PORST is high then you must observe signal ESR0 with oscilloscope when you generate a PORST via button. If the ESR0 is always low and will not go to high sometimes after PORST goes to high, then there the device is bricked maybe trough wrong/invalid configuration of UCBs.

[Teoman]

I saw the schematic and I am confused there must be changes on the board. I will check voltage supplies. I have a question. Does not the fact that the reset led(red) is on state means that the PORST signal is high? Could you please explain why the problem does not related to TLF35584 ? I will check ESR0 but I am confused TriBoard manual says that RST LED (/ESR0). 

[MoD]

Sorry was my mistake, the ESR0 pin is not available on this device. D504 shows here the state of PORST. The LED is always on which means that signal PORST is always low. The question is why, therefore you must check all supplies.

As long as PORST is low it is not possible to connect the device via any debugger.

If there is a problem with TLF35584 (e.g. safety features are active) then the TLF35584 will be switch off completely which result that also the red LED can't be on. The red LED is always on which shows that you have a stable voltage and the TLF35584 is not switched off.

It seems that there are some changes on the board itself which results now that the device is going out of reset. When we know which changes are made, maybe it is possible to explain the behavior. 

[Teoman]

Is there any possibility about TLF35584 is in sleep mode rather than failsafe state? Can TLF35584's sleep mode prevent the debugger process ? I will check the voltages and try to find fault places. Thank  you so much. I will inform you asap. 

[MoD]

No, there is no sleep mode on TLF35584. The access with debugger is prevented by the PORST, which is low.

[Teoman]

Sorry I have a news, the power LEDs(3.3 V and 5 V(V_UC) ) is already on state with reset LED. The contrast is very low so that I thought they are off. As a result, power supplies seem to be okay. But PORST pin still continue at low level. I connect a logic  analyzer and reset via debugger while power on the board. PORST pin does not go high, always in low. But interesting thing is that TLF does not shut down the supply of microcontroller(3.3V and 5V) after reset procedure. While TM pin at 5V, why PORST pin is driven to low state by TLF35584?  

[MoD]

It is not sure that the TLF35584 drive the PORST signal low. I guess the TC332 drive the PORST low because there is e.g. VDD missing. You should measure also VDD which is generated by TC332 itself. This is the other green LED which should be also on when VDD is ok. If VDD (1,25V) is not available then it seems that the TC332 is damaged otherwise you must check who drive the PORST low.

[Teoman]

Hello again, I solved the reset led issue, CPU pins is bending in the socket. I fixed the cpu pins and after that the 3 green LED is on(V_CU,3.3 and VDD). Also, the PORST pin is 5V and when I push the reset button the red LED is on and after that off. TM pin of TLF is 5V again. EVEN THOUGH, I cannot connect the isystem dubugger  to TC332 Eval Board. "SoC Attaching" error continue. What can be the reason in this situation  ?

[MoD]

Check the JTAG/DAP pins, maybe there is bending also any pins in the socket. From CPU side is now everything fine, the device boots and dependent of previous programming he is in Generic BSL. Connect the TriBoard via USB to your notebook. Previous install the DAS server (www.infineon.com/das). After installation you can open the device scanner, there should be shown your board (UDAS server must be run).

[Teoman · Accepted solution]

I solved the problem finally. The reason was the pins of CPU, most of them bended because of the no stabilized socket structure. I tried to fix the microcontroller pins and aligned due to the socket pins.

Thank  you for your passion and answers.  Best Regards.