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
!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.
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!
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.
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.
Thanks for your help .
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?