Use P2 to program FPGA as JTAG (it's working!)

Rayman · 2021-11-12 17:50

Attempting to use this .svf JTAG code to program a TinyFPGA AX2 using P2 as JTAG programmer.
This is in FlexProp C.

It's doing something, but doesn't seem to actually work yet...

It has a mode to return the idcode and version numbers from the chip.
This returns some values, but still trying to figure out if they are right or not.

Update: It works! Seems I didn't read the instructions carefully enough and left off something that was needed in the h_udelay() function. Only problem now is that it's slow...

Rayman · 2021-11-12 18:23

It's possible that the code is working, but that the .svf file that the Diamond Deployment Tool creates is not compatible...

Had to pick "RUNTEST from Rev C" and "For Erase, Program, and Verify Operations, Skip Verify" options to get it to complete without errors.

Rayman · 2021-11-12 20:08

Ok, I think I've confirmed that the output of the check id function is correct:

( Entering terminal mode.  Press Ctrl-] or Ctrl-Z to exit. )
clock freq= 160000000
TDO= 50
Starting...idcode=0x012ba043, revision=0x0, part=0x12ba, manufactor=0x021
Total number of clock cycles: 79
Number of significant TDI bits: 64
Number of significant TDO bits: 0
Finished without errors.

Found some code that shows it here: https://github.com/YosysHQ/prjtrellis/blob/master/devices.json
Also, the manufacturer code appears correct.

Also, by adding comments to the .svf file, I believe I'm seeing instructions to check the id code before programming.

Still don't know why the programming doesn't seem to work though...

Rayman · 2021-11-13 18:44

It's working! Was missing a key piece of code in the h_udelay() function.
Only problem now is that it's slow. Takes a ~3 minutes to program.
Could be my new h_udelay() function needs a speed improvement for cases where num_tck>0.
Still, this is a huge advancement for my P2 <-> FPGA interfacing...

jmg · 2021-11-13 19:26

@Rayman said:
It's working! Was missing a key piece of code in the h_udelay() function.
Only problem now is that it's slow. Takes a ~3 minutes to program.
Could be my new h_udelay() function needs a speed improvement for cases where num_tck>0.
Still, this is a huge advancement for my P2 <-> FPGA interfacing...

Good progress
You could have the SW total the programming low pulses and compare that with overall pgm time.

When I was doing SVF on Atmel CPLDs, I found time spent in PGM wait was ~60%, vs ~40% in comms link work.
Atmel CPLDs send fuse-strips that matched the device wide-or - do Lattice parts use a boot FLASH ?

Rayman · 2021-11-13 21:05

@jmg I barely know what I'm doing here...
But, I think you are right because when I did "verbose" mode, I saw that the main delays were calls to that h_udelay() function calling for millions of clocks of either all 1 or all 0.
I'm guessing this is a delay after erasing flash, but don't know.

I think there is a boot flash that I'm programming.
I think this gets loaded into a configuration SRAM on boot.
However, I think it's also possible to just load SRAM configuration directly.
I've read that this is faster and should be the normal way during development.
Looks like loading the SRAM can also be done via SPI or I2C...

Rayman · 2021-11-13 21:21

Sped it up a bit like this:

    if (num_tck > 0) 
    {//toggle cloce with tms set to input value
        io_tms(tms);
        while (num_tck > 0)
        {
            _pinw(pTCK, 0);
            _pinw(pTCK, 1);
            //io_tck(0);
            //io_tck(1);
            num_tck--;
        }
    }

Surprised that made a difference... Guess I really need to do some inline assembly.
I see the line that causes the biggest delay:

! Erase the Flash

! Shift in ISC ERASE(0x0E) instruction
SIR 8   TDI  (0E);
SDR 8   TDI  (0E);
! wait 1.50e+001 SEC
RUNTEST IDLE    15000002 TCK;
! Shift in LSC_CHECK_BUSY(0xF0) instruction
SIR 8   TDI  (F0);
SDR 1   TDI  (0)
        TDO  (0);

This causes it to toggle the clock 15 million times. Does look like a delay after giving the erase flash command...

Rayman · 2021-11-13 21:22

It now passes the "verify" step, after programming. Probably a good sign.

Rayman · 2021-11-13 21:46

Changed to inline assembly and load time is now ~30 seconds.
Getting closer to being useful...

    if (num_tck > 0) 
    {//toggle cloce with tms set to input value
        io_tms(tms);
        int tck_pin = pTCK;
        __asm {
        AsmLoop
            DRVL tck_pin
            DRVH tck_pin
            DJNZ num_tck,#AsmLoop
        }
        /*
        while (num_tck > 0)
        {
            _pinw(pTCK, 0);
            _pinw(pTCK, 1);
            //io_tck(0);
            //io_tck(1);
            num_tck--;
        }
        */
    }

jmg · 2021-11-13 23:17

@Rayman said:

I think there is a boot flash that I'm programming.
I think this gets loaded into a configuration SRAM on boot.
However, I think it's also possible to just load SRAM configuration directly.
I've read that this is faster and should be the normal way during development.
Looks like loading the SRAM can also be done via SPI or I2C...

Yes, I think modern CPLDs use a separate flash die, that loads, as that better matches speed and costs.

I'm guessing this is a delay after erasing flash, but don't know.
This causes it to toggle the clock 15 million times. Does look like a delay after giving the erase flash command...

Is that assuming a 10MHz or 1MHz clk ? - does sound like a chip erase step of flash die.

What is the delay time allowed per-flash-page pgm ?

Changed to inline assembly and load time is now ~30 seconds.
Getting closer to being useful...

Sounding good. Could the clock risk be getting too fast on P2 ? - maybe a NOP to give a 50% duty clk ?

Use P2 to program FPGA as JTAG (it's working!)

Comments