66AK2G12: Error connecting to the target:(Error -6305) PRSC module failed to write to a router register.

Hello Hidekazu,

Please provide more information about your hardware setup and connections.

1) What do you mean by "connect to 66AK2G12 with ICE"?

2) I assume you are able to successfully connect to a K2G TI EVM, and your debug connection is not working only with the custom board?

3) Is there any other hardware information we should know?

Regards,

Nick

Hi,Nick

Thank you for Rreply.

The hardware is designed for the custom board using the circuitry of the evaluation board as a reference.
We will comment the following questions inline (>>).

1) What do you mean by "connect to 66AK2G12 with ICE"?
>> It means connecting a custom board via XDS200 emulator.

2) I assume you are able to successfully connect to a K2G TI EVM, and your debug connection is not working only with the custom board?
>> When I try to connect with a custom board, an error occurs and I cannot connect.

3) Is there any other hardware information we should know?
>> The custom board is designed based on the circuit of the evaluation board.
It is possible to get Setup information from the customer if necessary.
What information do you need to resolve this issue?

Best Regards,
Hidekazu

Hello Hidekazu,

I am routing your thread to another team member to take the next steps.

Regards,

Nick

Does the custom board show any other signs of life? Have you confirmed the custom board is sourcing the appropriate power supplies, reference clock, and reset? Have you used a scope to see if there is any activity on the TRSTn, TMS, TDI, TDO, and TCK JTAG signals when trying to connect? Are the EMU[1:0] inputs pulled high?

I will assign this thread to our CCS team and ask them to comment on this error code if your answers to my questions do not reveal any cause.

Regards,
Paul

Hi,Paul
Thank you for your comments.

We have investigated the custom board (around the hardware).
There were some circuit differences from the evaluation board, so I corrected them and checked the timing of the JTAG signal datasheet, and it was as specified.

However, RESETSTATn is low and I am concerned that the device is being reset.
I have confirmed that the only resets used are the PORn and RESETn pins, both of which are high.
There is another reset signal, LRESETn.
This one is unused and is assumed to be pulled up internally and is open.
Are these the reasons why RESETSTATn is low?
Or is there another factor that causes RESETSTATn to be low?

Best Regards,
Hidekazu

Hi,Paul

Thank you for Reply.

The customer had already seen the annotation in the TRM, but interpreted it as "not to be connected to GND".
What should be the general interpretation that it should not be connected at the board level?
(They would like to have confirmation information that this will remove the reset condition.)

Best Regards,
Hidekazu

I agree, none of the reset inputs should be connected to ground since this would hold portions or the entire device in reset.

We are still investigating if it is possible to leave any of them unconnected.

The original design team is no longer available to ask questions, so we are looking through internal documents trying to understand how the device reset inputs were implemented. We found a document that says the state of RESETSTATn is only a function of PORn, RESETn, and RESETFULLn. If this is true, I would not expect the state of LRESETn to cause the problem you are reporting.

What did you do with the RESETFULLn pin?

Regards,
Paul

We found something else in our internal documents that indicate the internal pulls on some of the reset inputs may get turned off after the PORn is released. If so, it would not be possible to leave any of the inputs unconnected as they could float low. We are still researching this to confirm. If so, this would explain the note in the TRM.

Hi,Peaves
Thank you for information.

This is due to the impact on custom board modifications and development schedules,
We appreciate your early analysis and disclosure of information.

Best Regards,
Hidekazu

You didn't answer my question about how RESETFULLn is connected in your design.

Regards,
Paul

Hi,Paul
Sorry for the lack of confirmation.

The current RESETFULL process pulls up the 3.3V power supply with a 4.7kΩ resistor.
It will go "H" when the power supply is turned on.

The reference manual states that the device should be kept low for 150 usec after
the power supply has stabilized, but we are still checking to see if this requirement is met.
We also compared the signal on the evaluation board, and it seemed to rise at the same timing
as the power supply on the evaluation board.

Otherwise, we are checking the relationship between LRESETn and RESETSTATEn on the customer side,
but could not confirm this from the datasheet.
This is because RESETSTATEn is introduced as an indicator of Global Reset, but LRESETn is not Global Reset.
Also, I am beginning to think that the initial ICE not being connected and RESETSTATEn being L
(which is of course a problem) are not necessarily connected.
It seems to me that it is meaningless to use the RESET_STAT register to see the state of the
global reset if the ICE is not connected.

Best Regards,
Hidekazu

I do not know what is holding the device in reset, where RESETSTATn is driven low. This should not be the case, if all three inputs PORn, RESETn, and RESETFULLn are high. I can only assume they have a power supply problem or an issue with their reference clock source.

How many PCB assemblies has your customer built and how many of them are experiencing this problem?

Regards,
Paul

Hi,Paul

Thank you for Comment.

The incidence of this phenomenon (being confirmed by the customer) is based on the fact
that the debug evaluation has been stopped. We believe that the problem is occurring
on all PCBs we have created.

Incidentally, is it your understanding that the internal documentation found
"indicating that the internal pull of some reset inputs may turn off after PORn is released"
does not apply to this case?

You indicated that there is a problem with the power supply or the master clock,
Where should we focus our checks ?

- Reference information -

The customer is using a TPS65911A (PMIC).

TPS65911A User's Guide for 66AK2G12 Processor
www.ti.com/.../swcu187a.pdf

The PWRDN_POL setting on page 9 of the TPS65911A User Guide for 66AK2G12 Processor
is "1", so the PWRDN pin is set High and powered down.

From TI, in Figure 2 on page 3 and Figure 7-1 on page 121 of the datasheet,
If not used, connect to VRTC", which turns out to be a misnomer,
It was pointed out that "If not used, connect to gnd" is correct.

As a result, the PIN process is as follows.
1. PWRDN is active high.
2. If PWRDN is unused, connect to GND. No resistor needed.
3. PWRON has an internal pullup enabled by default. You can leave PWRON not connected (NC) if unused.

Best Regards,
Hidekazu

The concern with internal pulls on reset inputs being turned off was related to the two local reset inputs not the inputs that effect RESETSTATn.

I suggested checking your reference clock source because the device is synchronously released from reset. The device will never exit the reset condition without a reference clock.

I'm not able answer any questions related to the PMIC. You should ask these questions on the appropriate PMIC E2E thread.

Your customer needs to explore everything that is different on their custom board design to understand what is causing the device to never come out of reset. It may be necessary for them to modify their PCB to make it match the TI evaluation platform one change at a time until they discover what is causing the problem. I do not sure how we can help the customer debug this problem. 

Regards,
Paul