SM470R1B1M does not reset by JTAG

Andrew, a 10 ohm pullup sounds like an issue.
Could you provide schematic?
Regards,
Wade

Thanks for your response, I am just working out how to send you this schematic.

I received your schematic.

I am certain that JTAG cannot reset the system via nSRST due to the 10ohm pullup (short) to 3.3v.  The emulator pod cannot sink enough current to activate reset.

Is the only node of RSTN to the jtag connector?  Ie, no other components driving this net?  I did not see any others in what you provided me.

RSTN is an I/O with open drain output on the R1B1M.  If it is not driven low by the processor, it should be high impedance, and should only require nominal pullup to keep it at valid logic high.   The source of the issue requiring a 10 ohm pullup needs to be found.

Regards,

Wade

Thanks for your response.

The RSTn pin is indeed connected only to the pull up resistor (10R) and the associated JTAG pin.

We have two boards configured the same way - on the second board (even with the 10R resistor) the JTAG is able to reset the processor (well, at least the processor can be programmed). The two boards have not been treated differently and all the connections are intact right up to the package.

There is (understandably) very little information on what is inside the processor at the reset pin which left me at a loose end when I had to fit the 10R. Your thoughts on the PORRSTn pin might lead us towards this issue however. I have measured it and it is "stuck" at 1.5x volts though the system is operational. Infact, it has been working fine.

The system is based (as closely as possible) on the HEAT EVM schematic though obviously there is no power supply circuitry on there.

Kind thanks for your help so far,

Andrew

Andrew,
The RSTn pin is rated at 4ma sink. With a 10ohm resistor, it would need to sink upwards of 200ma in order to generate a valid logic low externally. This is its purpose, as a signal to the rest of the system that it is in reset. It also serves as an input when (when not in reset) that will trigger a reset from another device in the system.
You needing a 10ohm resistor is a sign that something is wrong.

Having PORRST not reach valid logic high is also a major issue.
This looks to be a result that it has a very weak pullup to 3.3v. It looks to be 100k on your schematic.
PORRST has an internal 20uA pulldown. This is nominal value, so they can vary by a bit.

Please add stronger pullup for PORRST, and see if that resolves the need for 10ohm resistor and the jtag reset issue.
I would suggest a 10k ohm.
Regards,
Wade

Hello,
I have changed the PORRSTn pull up to a 10k and this pin now is behaving as I would have expected. That makes sense. In doing so I have been able to change the pull up on the RSTn pin for a 10k and now see the RST line toggle when JTAG programming commences. I have done this on both the working and non working boards and get sensible, expected behaviour now. That's a good spot, thank you.

Sadly, the problem of one of these boards failing to program continues (with the same error message as before).

I have not managed to find documents relating specifically to how the JTAG works on the TMS/SM470 processors such as what commands are performed and in what order. What I can tell you is that the TRSTn pin resets 3 times before the JTAG programming sequence fails (I presume this is where it tries to erase the flash rather than program it). The programmer continues to be able to retrieve the chip ID Code which suggests the JTAG is working as before. Up to this point the communications are almost exactly identical to those of the working board. I suspect the difference is related to the ID code which is different per device.

Thanks for your assistance so far, if you can suggest any futher test avenues I would be very grateful

Andrew

Andrew,

It is conceivable that the processor was damaged due to PORRST being held in an indeterminate value.  This could have high through current in the input transistor structure possibly damaging it.  Also could possibly have corrupted the FLASH banks due to activating/deactivating the FLASH controller as noise on the input causes the input to see high and low values.

I cannot be certain of this, but it is suspect.

Can you replace the unit? to verify?

Do you have power up/down ramp plots?  Are they meeting PORRST/RST requirements as well?

Regards,

Wade

Wade,

Thanks very much for your comments. The power up sequence is as required even with the change in resistor values. This was a modification we made to our design at prototype stage. Unfortunately, except for our second board (which works with these modifications) we have no alternative part to try and cannot simply swap out the component.

I think we have reached the point with your help where we should look into obtaining a replacement part but do have a more reliable power up and reset circuit than we started with.

Thanks again for your assistance,

Andrew

Wade,

Before we close this thread as it has run its course I wondered if you had a comment on the following:

This issue arose whilst we were exploring power saving features on the processor. Although I wrote quite a bit of the firmware for this product I didn't write any of the power saving code. Over a drink at the weekend I wondered the following -
if the processor enters the "halt" mode soon after startup is it possible that this would put things like the flash clocks and so forth to sleep thus preventing the processor from being programmable. If this is the case, do you recall any existing threads which might suggest how to recover from this scenario. We are using Keil and a uLink 2.

Thanks for the final time,

Andrew

Andrew, I would not expect this to be the case. The emulator should be reseting the device and loading the flashloader software independent of the devices current state. The flashloader should be putting device into correct configuration to erase/program.
The flashloader loads the flash API, and code to perform the erase and program.
The API requires knowledge of the clock frequencies to properly time the flash controller. I am uncertain how this occurs with the Keil and ulink2. Keil likely can answer how, and what values get passed to the flashloader. If these are incorrect, it could cause the erase to fail.
Regards,
Wade