RE: TMS470R1B1M IAR J-link connection failed. Failed to measure TotalIRLen.

I think this was split/moved while I was posting reply.

Here are my replies to original post.  Also link to original post

http://e2e.ti.com/support/applications/hirel/f/935/t/250847.aspx

--

Andrew,

I had not seen the original post for these issues.  The SM470 Tag notified me.

It appears that there was not any feedback from customer on resolution(or lack of) for this issue with them.

Also, it appears that some of the embedded images with logic analyzer are no longer available to review.

Original customer issue does not properly power up device, so I am not certain if this is related.   (the PORRST timing must be delayed to properly inhibit the flash state machine from corrupting flash during power up/down)  I would not expect this to cause JTAG issues, but thought it was important to note.

Additionally, he indicates RSTn is tied to 3.3v.  This is an issue, as RSTn is an open drain output/ with input.

Note sure what you mean by disconnecting other comm channel.

In cases where it does not work, is TDO response from R1B1 always 0?

Are you using full 20pin ARM header?

Regards,

Wade

Hi Wade, thank you for looking into this for us.  Answers are listed below:

  - PORRSTn is tied to 3.3 V through a 10KΩ resistor and has a 0.1 uF grounded capacitor.
        - welcome your suggestions - the TI H.E.A.T. EVM schematic offers no clues, it appears as if the signal is floating.

  - RSTn (pin 69) is pulled up to 3.3 V through a 10KΩ resistor and is tied to JTAG NRESET

  - The other comm channel was an external USB to RS485 converter.  After hours of "Failed to measure TotalIRLen" we got good programming when the 485 connection to this adapter was removed.  The USB end of the converter was not connected.  Later the "Failed to measure TotalIRLen" error message returned even though the 485 converter was disconnected.  As explained to me by the f/w expert there are several ways to program the micro and so any stray communication should be avoided.  The RS485 comms are converted to single ended TX and RX signals and are connected to SCI1RX and SCI1TX.

  - TDO goes low for 400 us then toggles data for a while, has another few hundred us low then goes high

  - We are using the following pins from the ARM header: ground / TCK / TDI / TDO / TMS / TRSTN / NRESET / VTref (3.3 V)

On my board TRSTn has the option of being pulled up or down.  The datasheet recommends low.  The reported f/w experience has been that things "are much happier" (i.e. work) when it is pulled high. In spite of that, and given that the H.E.A.T. board has it tied low I have just tried an experiment, modifying the f/w dev board to give TRSTn a pull down.  It gave me a good connection...while this is nice it is worth noting that we had good connections for a long time yesterday with TRSTn pulled high.

I *may* have solved the problem but would welcome your thoughts on the answers to your questions, above.  I am also very interested to get your thoughts on our PORRSTn configuration.

Best Wishes,

Andrew 

Andrew,

PORRST on the HEATEVM should have been connected to the power header JP2 and fed from board that supplies power.

There is risk of corrupting the flash if PORRST is not asserted during power up/down.  Please see the datasheet for PORRST requirements.

I believe your RSTn connections are acceptable.

I could believe that noise could potentially cause some behavior change, but does not seem likely that connections to the SCI pins would have any affect on JTAG operation.

With respect to the pull down for TRSTn.  This is typically pulled low, to hold the JTAG controller in reset if there is not an emulator connected.  This may have left the JTAG controller in an unknown state in some cases and impacted the connection.  I would expect the the emulator to pulse it low prior to communications, but I am not sure.

Glad that it is working more reliably.

Regards,

Wade

Wade,

I think we either meet or can meet with minor adjustments the power up side of PORRSTn.  The shut down side looks a bit more complex to meet, requiring advance knowledge or charge storage to cover situations where a battery supply is abruptly removed. 

Does the flash corruption happen only if flash writes are happening at the moment of power down (e.g. by battery removal) or can it get corrupted even during non-flash related micro operations if/when power is removed abruptly?

Andrew