Are there any special sequences or other requirements to get MAX10 to respond to JTAG ?

DMcLa3 · ‎01-24-2019

Our design has a MAX10 (10M16SCU) and we would like to program it with JBC for field updates. We have been unable to get the embedded player software to work.

For debug, we fell back to a simple test where we try to read the IDCODE. This works fine with the Altera tools, as well as a simple SVF we created. When we do this same sequence on our embedded process, there is no response from the device (TDO is always 0).

The SVF code that works is

STATE IDLE;

!

!Max 10 IDCODE

!

!SIR 10 TDI (006);

!RUNTEST IDLE 128 TCK ENDSTATE IDLE;

SDR 32 TDI (00000000) TDO (031830DD) MASK (FFFFFFFF);

(this was taken from an SVF generated by the Quartus tools). It works fine and TMS, TCK signals are as expected.

When we duplicate this sequence on our embedded processor, we get no response.

Sequence is

TMS=1 for 6 TCK (reset JTAG state to TLR)

TMS=0 for 1 TCK (move to RTI state)

TMS = 1 for 1 TCK( move to SELECT_DR)

TMS= 0 for 1 TCK ( move to CAPTURE_DR)

TMS = 0 for 1 TCK (move to SHIFT_DR)

TMS=0 for 31 TCK (shift out DR, stay in SHIFT_DR)

TMS=1 for 1 TCK (shift bit32 from DR, move to EXIT_DR)

TMS=1 for 1 TCK (move to UPDATE_DR)

TMS=1 for 1 TCK(move to RTI)

The JTAG works fine with all the Altera tools so we know the port is OK. The embedded CPU only takes control of the JTAG during programming, but are otherwise tri-state with pullups on TMS, TDI, and a pulldown on TCK. We have verified this.

Any ideas what could be wrong? Any help appreciated!

ShafiqY_Intel · ‎01-25-2019

Hello, How about your TCK frequency? Do you set it to default TCK frequency value (6MHz)? I suspect this more towards the JTAG protocol. Please follow the IEEE JTAG protocol regarding to this issue. Thanks.

DMcLa3 · ‎01-25-2019

Our interface uses GPIO from an microcontroller so timings are very slow: TCK is ~250 kHz. Setup times for TDI and TMS are >1 uS.

We also suspect protocol. Our end goal is to get the JBC player working on the embedded processor; these tests are just to debug that interface since it did not work.

Does the MAX10 load its ID code when the JTAG state machine is set TLR state? This is optional in the JTAG spec but we are looking for simple ways to debug this and if so, would simplify the test?

Thanks for your help.

ShafiqY_Intel · ‎01-28-2019

Hi, For TCK frequency, Can you make it a little bit faster? 250kHz is too slow. Do you mean you want to do JTAG boundary-scan testing (BST)? You may refer to the following user guide for JTAG BST. https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/max-10/ug_m10_jtag.pdf As far as I know, Max 10 do not need to loads its id code. Only JTAG ID is needed for verify process. The following are the recommended flow to program MAX 10: 1. Check ID—the JTAG ID is checked before any program or verify process. The time required to read this JTAG ID is relatively small compared to the overall programming time. 2. Enter ISP—ensures the I/O pins transition smoothly from user mode to the ISP mode. 3. Sector Erase—shifting in the address and instruction to erase the device and applying erase pulses. (UFM and DSM sectors) 4. Program—shifting in the address, data, and program instructions and generating the program pulse to program the flash cells. This process is repeated for each address in the internal flash sector. (UFM and/or DSM sector) 5. Verify—shifting in addresses, applying the verify instruction to generate the read pulse, and shifting out the data for comparison. This process is repeated for each internal flash address. (UFM and DFM sector) 6. Exit ISP—ensures that the I/O pins transition smoothly from the ISP mode to the user mode. Thanks.

DMcLa3 · ‎02-11-2019

Thanks for your reply.

We are not trying to do BST. We just had problems getting the JBC programmer working on our processor and thought we would try a few simple tests to see what is wrong.

The first test we tried was to read the IDCODE, thinking that is very basic. What we found was that the MAX10 did not respond at all. No TDO output when we try to use our embedded processor.

The JTAG chain on our design is minimal: just the MAX10 device in the chain. The JTAG pins go to a header and also to the processor.

The Altera cable works fine with the MAX10 , but the CPU does not. We can use SignalTap and program the logic without any incident.

We have verified several times that the CPU is not interfering with operation. This is the first place we looked, then looked twice again.

We looked at the timing when the Altera bitblaster reads the IDCODE and verified both our timing and protocol.

The signals also have good quality from the CPU with no overshoot, ringing or non-monotonic behavior. Power is good and within spec .

Despite all this, the max10 is unresponsive to the JTAG when driven by our CPU. I have spent may hours reviewing documentation and anything I can find on the support site and web. Nothing seems to give any hint.

Any ideas?

Thanks for your help .

DMcLa3 · ‎02-11-2019

BTW why do you say 250KHz is too slow? I thought JTAG is driven by rising edge TCK . I know it would be slow, but we thought we can work the speed once we solve this problem. Is there any concern other than the programming time?