#apertus IRC Channel Logs

ok

do I have to 'reboot' the lattice after programming it?

hrm

check with ./cmv_init.sh if it works

note that you managed to get it working before, so we should be able to figure that out

right

i.e. repeat the steps, and see when it starts working

fair enough, try to disable it (this time without deleting it :)

i.e. systemctl stop cmv12k

yep

are your shunt resistor values correct?

*high

one sec

beta/sensor part is a little high

the temperature or our problems?

err s/temperature/current draw/

sec, checking

yes, with the icsp.bit loaded, the RFE seems to work fine

f671a9a98f7bbbc38636aab43954e979 icsp.bit ?

so I guess I need to break out the Logic Analyzer then

unless you can think of some other way to validate this

ok

reboot

./power_on.sh

./icsp_sel.py B

that's where I'm at

brb digging for a heatsink

hrm

and re-programmed both

well, strictly speaking I didn't clear them, just overwrite them

especially since we got it working once

we did change some feature flags

they configure the FPGA, but I tried with 0000 and 0620 here

both work fine here

the dump doesn't help you, I'm using a XO2 2000 here

but I don't think the MachXO2 makes a difference

https://gist.github.com/John-K/b4df98812f03d8ee477f

ah

and just use cmv_hdmi3.bit

just load the cmv_hdmi3.bit and try a sel A/B

it actually should with the proper cmv_hdmi3.bit

(which provides the I2C bus)

okay, so let's work around that for now with configuring the PIC with icsp.bit first

curious

ah wait

power?

rebooting to try this fresh

with hdmi3

ok I have B selected

try to set 'sane' defaults for the PIC with icsp.bit in a script

using the i2c_set?

yes, the PIC has the following registers:

basically the tris gives the direction, the latch the output value

so tri and pullup to 0xFF and latch to 0

for tris a '1' means input

OTOH, that should be the default IIRC

please check what happens if you select the RFE

what do you mean by that?

so that i2cdetect -r -y -a 2 shows the 10's and 30's

and repeat the i2cdetect after that

10's 30's 70

oh wait, let me load cmv_hdmi3 that was my baseline check

okay, so the icsp_* commands will hang after the cmv_hdmi3

because you don't have the icsp serial interface

which makes total sense

(because you have the i2c bus in place)

so you can (manually) play around with the pic ports and see what makes the cmv SPI interface work

actually you can also manually switch that with

if the pic doesn't show up on the bus, try with ./gpio.sh init

so none of those ports should be outputs right?

the A port is basically all outputs except for A6 and A7 (which is unused)

well currently they're set to inputs on both our boards

the B port is trickier, as INITN and DONE can be input as well as output on the lattice

C6 is when you disable the JTAG port via the feature bits

and C7 is to restart the lattice

so C7 should be an output

and is it reset low?

but you can try pulling it high

btw, in I1+0^, I means input, what does the 1 mean?

and ^ means pullup enabled

i.e. what an output would get

so even though I write a 0 to the latch for C, C0,C1,C3 latch is always 1

the latch should reflect what you set

https://gist.github.com/John-K/45b74c27cd0ddb3fbd67

yeah, first the port, then the latch

pin is an input, the latch says '1' (i.e. output would produce a '1')

and a pullup is active (^)

so in my dump, only B7,C0,C1,C3 are reading as HI

ah

rb6/rb7 is the I2C bus, so they will give strange results

and C0-C3 is the JTAG interface

this is very strange that I still get 00000000 back from cmv_init though

okay, can you upload the gpio.py output again?

gpio.py (you played with that?) not pic_gpio.py

one sec

hmm, did you try ./gpio.py init ?

refresh the page

[22a6] CSE_EN O0+0^ confuses me

the enable line for the CSE (center solder on area, south east)

or should init set it high?

the init should enable it

just weird

okay, try to load the .cfg and .ufm via the pic_jtag_load.py

is 1151 the right # of pages for a 640?

and 192 for user

hrm

what about cmv_init.sh?

still 0

shouldn't INITN_E and DONE_E go high once it's running?

let me look up what would be correct there

are you looking at the datasheet or some other doc for this?

hmm ...

check page 3 of file:///Users/jkelley/Downloads/MachXO2ProgrammingandConfigurationUsageGuide.pdf

a falling edge on PROGRAMN will trigger a REFRESH

when the configuration fails, INITN will be pulled low

when the FPGA reaches the user mode, DONE will go high

the feabits can override the pins though

bit 5 is PROGRAM Persistence Disable

bit 7 is DONE Persistence Disable

so that is the '2' in 0620

hmm, right, so we want a 6 there

in TN1246

17-65

so if the DONE and INITN persistence is not enabled, they'll only go high for a short period?

so we probably want 06C0

and disable SPI, I2C, SlaveSPI but not JTAG

funny why the lattice tools use 0620 instead ...

yes, works here to get INITN and DONE up to '1'

so if I set program to output it should reboot the CPLD right?

but cmv_init doesn't work

I have to try a few times

icsp_* commands won't work

i2cset -y 2 0x70 0x0 0x4

yup

ok

pic_gpio errors out

?

i2cdetect -r -y -a 2

https://gist.github.com/anonymous/cc0d25c0c86e16bb49f2

./gpio.py init

same

https://gist.github.com/John-K/01524af79e0a364e1efd

your problem is that both pic reset lines are low

ah, I see, the init doesn't change the defaults

I don't see any code in gpio.py checking arguments either

if sys.argv[1] == "init":

not in the version I have :(

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/gpio.py doesn't have that either

uploaded the latest version

or well, not the power_on.sh per se, the fact that the reset lines default to low

sure, but power on should at least turn them on

no?

anyway, we can turn them on manually, so you can reach the PIC

i2c0_bit_set 0x23 0x14 4

trying

ok

first, does it properly initialize? i.e. do you get the INITN/DONE ='1'?

[B0] INITN_E I1+0^

okay, just to make sure, please run the following:

[root@beta bringup]# ./pic_jtag_refresh,py

status 00080100 [00000000000010000000000100000000] CFG=SRAM DONE SDMEN BSE=OK

cmv_init.sh still returns 0?

very strange

you can easily go back to the original state

i.e. everything, config, user, done, feature row/bits

yeah tried setting and not setting feature flags and cmv_init returns 0 each time

there is no indication that the lattice isn't working as expected

I'll try the other sensor PCB

and a scope on the respective pin

I'm still getting 0 with the other sensor PCB as well

I tell you, I have no clue at the moment

for example, you could connect the IO_SCL and IO_SDA

this way the other will change (as input) if the lattice is working correctly

I've added the necessary code :)

IO_SDA is forwarded to IO_SCL

ok will give it a shot now before I take a break

works here

i2c2_set 0x39 0x20

toggles IO_SCL as well

hmm, hmm ...

I was just figuring out those values myself

try that for cmv_init.sh

so, to sum it up, FPGA is working fine

so signs would point to something likely on the sensor side of the FPGA

sensor doesn't answer to SPI

right

it could be the dummy but I can't easily switch that out as my spare doesn't have the long header pins

one thing you can easily try out right now is to disconnect the power completely

make sure to run ./fclk_init.sh, ./power_init.sh and ./power_on.sh

ok

if they work fine, testing the SPI input is the next step, which is a little trickier

how is testing SPI input tricky?

well, it is an input to the zynq, over a level converter

which produces a pattern on the outputs (EN, CLK, SDO) which incorporates the pattern seen on the input (SDI)

input being something generated in software?

sdo <= sdi_clk xor sdi;

en <= sdi_clk;

sdi_clk and chk_clk are generated in the zynq

ah

well, that's how I tested the SPI bus back then :)

anyway, off to bed now ... have fun!

thanks

I got it to return 0x296 by moving a board slightly

John_K: yeah, I was suspecting the hardware at this point

a good way is to get a needle and try to move each pin sideways under a microscope

hey :)

fine, thanks! on your side?

sounds good!

indeed there is a price difference :)

I guess it's the focus area of my project - I settled on a HDMI-like interface which fits a bunch of extra data (flash strobes etc.) into the blanking periods

well, we have an 80 channel LVDS + a bunch of control lines (I2C, SPI) as well as six regulated voltages as interface to the SFE

ah ok going straight into the FMC

yes, the FPGA (zynq) will be reconfigured if necessary

the downside with my approach is that I must embed an FPGA into the sensor module

using Digilent's reference design I was actually able to get 1080p HDMI working on normal IO - I don't have enough experience to play around with the GBTs currently

well, the zynq is doing 1080p60 over "normal" LVDS

(although it requires careful placement there)

not within spec, of course :)

It is for the FSF to hand out as a flyer to video people

good evening

good night