I am in the process of writing a JTAG controller for an LH79520 board I am building. At this point I have been able to successfully access the instruction and data registers. To verify that things are working I have run loop back tests through the registers. The problem I am having is that none of the instructions in the bsdl are working . For example, if I try to run the IDCODE command (1110) I am put into BYPASS when I try to access the data register. From the JTAG spec, this means that 1110 is not being considered a valid code. This is in spite of the fact that I am getting a proper capture result when I clock my instruction into the instruction register. After some experimentation I have been able to connect the boundary scan chain and clock data through it, but the codes that give this result are completely different from the codes in the bsdl file. In addition I still have not been able to access the IDCODE register. I do not think it is a board problem, because I do have some code written for a JTAG/USB controller from Mesa Electronics that is successfully pulling the IDCODE. So at the moment I am totally baffled as to why IDCODE is not accessible and why none of JTAG instructions are working. I do have the source code for the controller from Mesa Electronics, but it is written for the Borland compiler. I have downloaded the free compiler from Borland and am attempting to get it running so I can enable the debug and see how it is able to get the IDCODE. In the mean time I am hoping someone may be able to offer some suggestions on what might be going on.
Problems with JTAG and LH79520
Started by ●April 14, 2004
Reply by ●April 14, 20042004-04-14
"db" <javaguy11111@yahoo.com> escribi� en el mensaje news:903bda3b.0404132051.441607f5@posting.google.com...> In the mean time I am hoping someone may be able to offer some > suggestions on what might be going on.- Check your TAP signal sequencing. Which physical interface are you using? TCK is idle-high or idle-low? - Check your TAP state machine sequencing. How are you exiting TAP states? How are you driving TDI and TCK in the last bit access of the shift states? Are you exiting to RUN/TEST_IDLE in order to run JTAG commands? - Check your bit ordering. Vendors often publish different bit orders and swap (MSB->LSB or LSB->MSB) descriptions. Check your JTAG instruction length. From my experience, most JTAG problems reside on the issues above. If you are unable to access IDCODE then you are doing something pretty wrong. Regards.
Reply by ●April 14, 20042004-04-14
"db" <javaguy11111@yahoo.com> escribi� en el mensaje news:903bda3b.0404132051.441607f5@posting.google.com...> I am in the process of writing a JTAG controller for an LH79520 board > I am building. > ... > > In the mean time I am hoping someone may be able to offer some > suggestions on what might be going on.- Check your TAP signal sequencing. Which physical interface are you using? TCK is idle-high or idle-low? - Check your TAP state machine sequencing. How are you exiting TAP states? How are you driving TDI and TCK in the last bit access of the shift states? Are you exiting to RUN/TEST_IDLE in order to run JTAG commands? - Check your bit ordering. Vendors often publish different bit orders and swap (MSB->LSB or LSB->MSB) descriptions. Check your JTAG instruction length. From my experience, most JTAG problems reside on the issues above. If you are unable to access IDCODE then you are doing something pretty wrong. Regards.
Reply by ●April 14, 20042004-04-14
"db" <javaguy11111@yahoo.com> escribi� en el mensaje news:903bda3b.0404132051.441607f5@posting.google.com...> I am in the process of writing a JTAG controller for an LH79520 board > I am building. > ... > > In the mean time I am hoping someone may be able to offer some > suggestions on what might be going on.- Check your TAP signal sequencing. Which physical interface are you using? TCK is idle-high or idle-low? - Check your TAP state machine sequencing. How are you exiting TAP states? How are you driving TDI and TCK in the last bit access of the shift states? Are you exiting to RUN/TEST_IDLE in order to run JTAG commands? - Check your bit ordering. Vendors often publish different bit orders and swap (MSB->LSB or LSB->MSB) descriptions. Check your JTAG instruction length. From my experience, most JTAG problems reside on the issues above. If you are unable to access IDCODE then you are doing something pretty wrong. Regards.
Reply by ●April 14, 20042004-04-14
I did realize today that I have been getting the IDCODE if do as in the IEEE1149, by going to test-logic-reset and then shifting out the result from the data register. Still the idcode and other instructions are not working as I would expect them to.> - Check your TAP signal sequencing. Which physical interface are you using? > TCK is idle-high or idle-low?The application is written in java, goes through a USB connection to an ftdi chip, to an FPGA board built by Digilent and out to the LH79520. TMS and TDI values are available on the up clock of TCK and TDO is read after the down clock.> - Check your TAP state machine sequencing. How are you exiting TAP states? > How are you driving TDI and TCK in the last bit access of the shift states? > Are you exiting to RUN/TEST_IDLE in order to run JTAG commands?Basically the sequence I am using is: run_test_idle().select_dr_scan().select_ir_scan().capture_ir(). Then I clock in tdi data on shift_ir(), then I do exit1_ir().update_ir().run_test_idle().select_dr_scan().capture_dr() and shift the data out. I have tried numerous variations on this to try to tease out any errors with being off a bit.> - Check your bit ordering. Vendors often publish different bit orders and > swap (MSB->LSB or LSB->MSB) descriptions. Check your JTAG instruction > length.I set up an eight bit counter to cycle through all possible instruction combinations to take into account anything up to 2 bit synchronization error. I still do not see anything being placed between tdi and tdo that would correspond to the opcodes listed in the bsdl.> > From my experience, most JTAG problems reside on the issues above. If you > are unable to access IDCODE then you are doing something pretty wrong.I do agree something is wrong. Regards
Reply by ●April 15, 20042004-04-15
javaguy11111@yahoo.com (db) wrote in message news:<903bda3b.0404141815.52cc6641@posting.google.com>...> I did realize today that I have been getting the IDCODE if do as in > the IEEE1149, by going to test-logic-reset and then shifting out the > result from the data register. > Still the idcode and other instructions are not working as I would > expect them to.Your signal sequencer is most probably correct then. But if you screw things up later you will continue screwing them thereafter (been there, done that ;^)> LH79520. TMS and TDI values are available on the up clock of TCK and > TDO is read after the down clock.But how is your clock between state transitions? It really doesn't matter much if you are consistent. Using TCK idle-high is better to ease some timings.> > - Check your TAP state machine sequencing. How are you exiting TAP states? > > How are you driving TDI and TCK in the last bit access of the shift states? > > Are you exiting to RUN/TEST_IDLE in order to run JTAG commands? > > Basically the sequence I am using is: > run_test_idle().select_dr_scan().select_ir_scan().capture_ir(). > Then I clock in tdi data on shift_ir(), > then I do > exit1_ir().update_ir().run_test_idle().select_dr_scan().capture_dr() > > > and shift the data out. > I have tried numerous variations on this to try to tease out any > errors with being off a bit.You still don't tell me how you are exiting the shift states. Note that the last bit should be shifted in parallel with toggling TMS to exit the shift state, otherwise data will roll over and you will shift wrong instructions. This is a common misconception about JTAG. If you post a detailed diagram of the JTAG signals sequencing that would be enlightening.> > - Check your bit ordering. Vendors often publish different bit orders and > > swap (MSB->LSB or LSB->MSB) descriptions. Check your JTAG instruction > > length. > > I set up an eight bit counter to cycle through all possible > instruction combinations to take into account anything up to 2 bit > synchronization error. > I still do not see anything being placed between tdi and tdo that > would correspond to the opcodes listed in the bsdl.It won't matter how much you permutate your instructions if you are shifting them erroneously ;^) Cheers!
Reply by ●April 16, 20042004-04-16
I was able to get confirmation of a bit off problem. I have another board that I built with two Xilinx CPLD's and chained together. While running the IDCODE opcode I was able to get one of the CPLD's to produce a correct IDCODE response when I offset the command by one bit. I tried to see if I could tweak the java code to control when the data was getting latched in, but that did not work. So I will have to get back into the the hdl. I have found a TAP core on the opencores.org website, that I can use to simulate with the hdl code I have written. I will let you know what I find. Cheers, Damon pablobleyer@hotmail.com (Pablo Bleyer Kocik) wrote in message news:<bb2f07d6.0404150751.222a3155@posting.google.com>...> javaguy11111@yahoo.com (db) wrote in message news:<903bda3b.0404141815.52cc6641@posting.google.com>... > > I did realize today that I have been getting the IDCODE if do as in > > the IEEE1149, by going to test-logic-reset and then shifting out the > > result from the data register. > > Still the idcode and other instructions are not working as I would > > expect them to. > > Your signal sequencer is most probably correct then. But if you screw > things up later you will continue screwing them thereafter (been > there, done that ;^) > > > LH79520. TMS and TDI values are available on the up clock of TCK and > > TDO is read after the down clock. > > But how is your clock between state transitions? It really doesn't > matter much if you are consistent. Using TCK idle-high is better to > ease some timings. > > > > - Check your TAP state machine sequencing. How are you exiting TAP states? > > > How are you driving TDI and TCK in the last bit access of the shift states? > > > Are you exiting to RUN/TEST_IDLE in order to run JTAG commands? > > > > Basically the sequence I am using is: > > run_test_idle().select_dr_scan().select_ir_scan().capture_ir(). > > Then I clock in tdi data on shift_ir(), > > then I do > > exit1_ir().update_ir().run_test_idle().select_dr_scan().capture_dr() > > > > > > and shift the data out. > > I have tried numerous variations on this to try to tease out any > > errors with being off a bit. > > You still don't tell me how you are exiting the shift states. Note > that the last bit should be shifted in parallel with toggling TMS to > exit the shift state, otherwise data will roll over and you will shift > wrong instructions. This is a common misconception about JTAG. > > If you post a detailed diagram of the JTAG signals sequencing that > would be enlightening. > > > > - Check your bit ordering. Vendors often publish different bit orders and > > > swap (MSB->LSB or LSB->MSB) descriptions. Check your JTAG instruction > > > length. > > > > I set up an eight bit counter to cycle through all possible > > instruction combinations to take into account anything up to 2 bit > > synchronization error. > > I still do not see anything being placed between tdi and tdo that > > would correspond to the opcodes listed in the bsdl. > > It won't matter how much you permutate your instructions if you are > shifting them erroneously ;^) > > Cheers!
Reply by ●April 18, 20042004-04-18
Just following up on what has happened. I have been able to get things working with the LH79520. I had two things that I fixed to get things working. I am not sure if it is the "correct" way, but it works for me. 1. The last bit shifted into IR and DR must be done when entering the exit_ir or exit1_dr state. This got things working properly with the Xilinx part and I was able to run all commands and get correct boundary cell counts. 2. The LH79520 presented me with one other problem. When I ran EXTEST I was still finding myself off by one bit. I set up a boundary cell count test and found that the number of cells being returned is one more than what is in the BSDL file. I have posted a question to Sharp's LH79520 forum to see if I can find out what is going on. As a hack, I have just added in a dummy pin at the end of the boundary cell definition so I can move on. javaguy11111@yahoo.com (db) wrote in message news:<903bda3b.0404151957.7092d146@posting.google.com>...> I was able to get confirmation of a bit off problem. I have another > board that I built with two Xilinx CPLD's and chained together. While > running the IDCODE opcode I was able to get one of the CPLD's to > produce a correct IDCODE response when I offset the command by one > bit. > > I tried to see if I could tweak the java code to control when the data > was getting latched in, but that did not work. So I will have to get > back into the the hdl. I have found a TAP core on the opencores.org > website, that I can use to simulate with the hdl code I have written. > I will let you know what I find. > > Cheers, > Damon > > > pablobleyer@hotmail.com (Pablo Bleyer Kocik) wrote in message news:<bb2f07d6.0404150751.222a3155@posting.google.com>... > > javaguy11111@yahoo.com (db) wrote in message news:<903bda3b.0404141815.52cc6641@posting.google.com>... > > > I did realize today that I have been getting the IDCODE if do as in > > > the IEEE1149, by going to test-logic-reset and then shifting out the > > > result from the data register. > > > Still the idcode and other instructions are not working as I would > > > expect them to. > > > > Your signal sequencer is most probably correct then. But if you screw > > things up later you will continue screwing them thereafter (been > > there, done that ;^) > > > > > LH79520. TMS and TDI values are available on the up clock of TCK and > > > TDO is read after the down clock. > > > > But how is your clock between state transitions? It really doesn't > > matter much if you are consistent. Using TCK idle-high is better to > > ease some timings. > > > > > > - Check your TAP state machine sequencing. How are you exiting TAP states? > > > > How are you driving TDI and TCK in the last bit access of the shift states? > > > > Are you exiting to RUN/TEST_IDLE in order to run JTAG commands? > > > > > > Basically the sequence I am using is: > > > run_test_idle().select_dr_scan().select_ir_scan().capture_ir(). > > > Then I clock in tdi data on shift_ir(), > > > then I do > > > exit1_ir().update_ir().run_test_idle().select_dr_scan().capture_dr() > > > > > > > > > and shift the data out. > > > I have tried numerous variations on this to try to tease out any > > > errors with being off a bit. > > > > You still don't tell me how you are exiting the shift states. Note > > that the last bit should be shifted in parallel with toggling TMS to> > exit the shift state, otherwise data will roll over and you will shift > > wrong instructions. This is a common misconception about JTAG. > > > > If you post a detailed diagram of the JTAG signals sequencing that > > would be enlightening. > > > > > > - Check your bit ordering. Vendors often publish different bit orders and > > > > swap (MSB->LSB or LSB->MSB) descriptions. Check your JTAG instruction > > > > length. > > > > > > I set up an eight bit counter to cycle through all possible > > > instruction combinations to take into account anything up to 2 bit > > > synchronization error. > > > I still do not see anything being placed between tdi and tdo that > > > would correspond to the opcodes listed in the bsdl. > > > > It won't matter how much you permutate your instructions if you are > > shifting them erroneously ;^) > > > > Cheers!
