Jump to content
  • 0

DJTG returning incorrect bytes


Nichobeg

Question

Posted (edited)

I have some HDL that is passing JTAG to my serial flash and vice versa. I have been debugging for some time, but to my surprise I have now seen that the source of the issue is on the DJTG API side. 

I have attached some scope shots that show TDO (yellow) and TCK (blue). So this is ground truth. It can be a little hard to parse, but the expected byte pattern returned is 0x00 0x20 0xBA 0x18 (spi flash ID code). That is the data that is returned as shown in the scope captures. 

But the data in the tdi buffer is instead 0x00 0x30 0xBA 0x08. So you can see a bit is added and a bit missing. 

Here is a snippet of my DJTG api calls. Am I doing something wrong? I currently have the TCK set for 1MHZ conservatively. 

Any help is appreciated. Thank you. 

 

    BYTE rgbTdo[4];
    BYTE irShiftSetup[] = { 0xaa, 0xa2, 0x00 };
    BYTE user1CodeAndGotoShiftDr[] = { 0x04, 0xa8, 0x00 };

    BYTE dataCmd[] = { 0x40, 0x00 };
    BYTE tms[] = { 0x1F };

    BYTE getSpiIdTdiArray[1] = {0x9F};


    // reset and transition state machine to SHIFT-IR
    if (!DjtgPutTmsTdiBits(hif, irShiftSetup, NULL, 10, fFalse)) {
        printf("DjtgPutTmsTdiBits failed\n");
        ErrorExit();
    }

    // send User1 Code (0x02) and then transition to SHIFT-DR
    if (!DjtgPutTmsTdiBits(hif, user1CodeAndGotoShiftDr, NULL, 10, fFalse)) {
        printf("DjtgPutTmsTdiBits failed\n");
        ErrorExit();
    }

    // now we are connected to the SPI flash chip and we can directly clock
    // out the request for spi flash ID
    // 0x9f
    getSpiIdTdiArray[0] = reverse_bits(getSpiIdTdiArray[0]);

    if (!DjtgPutTdiBits(hif, fFalse, getSpiIdTdiArray, NULL, 8, fFalse)) {
        printf("DjtgPutTdiBits failed\n");
        ErrorExit();
    }

    if (!DjtgGetTdoBits(hif, fFalse, fFalse, rgbTdo, 24, fFalse)) {
        printf("DjtgGetTdoBits failed\n");
        ErrorExit();
    }
    

 

 

DS1Z_QuickPrint6.png

DS1Z_QuickPrint7.png

DS1Z_QuickPrint8.png

Edited by Nichobeg
fixing small typo
Link to comment
Share on other sites

2 answers to this question

Recommended Posts

  • 0

Hi @Nichobeg,

I feel like I must be reading the scope capture incorrectly; based on what I'm seeing, it looks like the data is being read in on the rising edge of TCK and changing state on the falling edge? 

Reconstructing the bit order based off your second screenshot and presuming the data is LSB first, I'm getting 0x00, 0x08, 0xBA, and 0x30, which matches the DJTG buffer (although not the order you listed):

image.png

Though as I'm typing this up, it occurs to me that if first clock edge is skipped (consequently shift increasing the MSB data by 1 bit), then the scope data will line up with the expected byte pattern of 0x00 0x20 0xBA 0x18, although the final bit in the last byte would seemingly not have a clock signal associated with it.

Let me know if I'm jumping down the right rabbit hole first before I try to help debug further.

Thanks,
JColvin

Link to comment
Share on other sites

  • 0

JColvin, 

 

Thanks for the reply! Now you've sent me down the rabbit hole! I am doubting my own reading of the byte order.

I am going to create a less ambiguous test value and fetch that to make certain I am reading this correctly. Stand by.... 

 

Thanks, 

N

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...