#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

Anybody available who has access to beta?

I meant root access :)

ah okay not me xD

I'm reading the files that on beta_e and getting lost

morning folks!

apurvanandan[m], aSobhy: good news, I wrote a bit file loader for the Beta which can load the MachXO2 SRAM much much faster

and you do not need to mess around with the svf files, just generate an SRAM .bit file

:D

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/jtagreg/

Is that right ?

OK

Bertl, Can I copy the contents on 1x USB 3.0 Plugin Module wiki page to Gearwork for USB 3.0 Plugin Module wiki page, as I think different wiki page aren't required for it

when in doubt, double check with se6ast1an or RexOrMatrix[m]

aSobhy, I am going to use beta, is it free?

Best link to existing content

Your page should contain stuff about your work, in the explanation you can of course link to other relevant pages like the hardware page of the plugin module

Can we use pic_jtag_bitload.py for programming the USB module also?

Thanks aSobhy

apurvanandan[m]: in theory yes, but it requires the bridge via the RFW

yup

Thanks Bertl thats save alot of time :)

Actuallt I meant for the .py file

Bertl: I tried what you suggested ie send 3 out of 4 data at ft601_clk

where 'no different' means?

Exactly same problem like previous method

it would be a perfect time to create a wiki page with the information what was tested (including setup, etc) and what problems were found

Sorry, let me explain in detail

I diagnosed that by putting at disable/pause condition on counter when FIFO is full and made write enable also zero at FIFO full condition

but give only 75% of data

did you check if the FIFO slowly gets full or stays basically empty till point X where the controller stalls and the FIFO runs full?

Okay forgot to check, checking that now

These numbers vary a little

otherwise you don't know if it gets slowly full or suddenly

(note that full is unlikely to end up in the FIFO :)

regenerate?

still using IPexpress ...

What do I say now :/

which should actually allow you to record 'full' in the FIFO

Bertl, please tell possible reasons for both slowly filling and abruptly filling. I will debug for both reasons

Okay, I have something to say here. I removed some 80 lines of useless code in the controller https://gist.github.com/apurvanandan1997/27a217c0cdc40d92343d748850d38837 and it doesn't retransmit at all instead when the fifo gets empty or the fifo inside ft601 gets full, it save 3 values taken out of the fifo for future transmission due to difference in timing of FT601_TXE_N and FT601_WR_N

In 245 Synchronous FIFO mode master read operation, the bus master shall be able to read out the maximum possible data in the RX FIFO in one read transaction, i.e. the bus master shall be able to read out 4 KB in one bus transaction. In write operations, if the bus master expects the data to be transferred on the USB bus in a maximum possible packet length, it should write the

doesn't matter much (i.e. it's now 'whatever' instead of 'retransmit, whatever')

excellent, let's see

why at the JTAGF_inst (TCK, TMS, TDI) are set to zero

and from the document JTCK is drived from TCK

off to bed

nn

aSobhy: the J* ports are only active for the ER1 instruction, and that's where you want to hook into

It gets completely full after some 7-10 thousand

Most of time it is almost empty

Anything else you would like to know?

So it seems there are abrupt pauses

158 words

how does a backlog of 158+ words arise?

aSobhy: you just ignore the access port TCK/TMS/TDI/TDO

and see what happens with unidirectional data transfer, 32bit on every clock cycle

These is the sequence of events : Normal routine ie empty after 14 clocks --> not almost emoty suddenly --> almost full in near time --> full

It just basic IO handling of FT601

(like turn around and idle, etc)

But all j* ports are output except JTDO

yup, precisely

I fixed the mode to ACTIVE Transmitting then also this problem was happening

And now the code doesn't have any bidirectional or retransmit or any thing like that

what is the config on the other side (PC)?

okay, needs more analysis

this way I can also easily test things

Thanks

(shouldn't take too long :)

okay, looks good, do we have a 'blink' bit stream for blinking the LED on the USB plugin module?

Yes I have that Bertl

Two times scp and writing ports, for download and upload!

Now just one word command for files and folder

:O

@blink please upload and provide the url for testing

Both svf and bit files on Beta now

I have a local setup for testing here ...

Location of file?

nevermind, I copy it from the beta ...

inside apurva_ws on both zbox and beta_e

yup, works like a charm

let me upload the scripts and provide some explanations

You will be able to resceive data from ft602