65Org16.x Dev. Board V1.1 using a Spartan 6 XC6SLX9-3TQG144

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Apr 03, 2012 11:26 am

I don't believe I was getting the acknowledge. I'll check this morning!

Arlet · Post by **Arlet** » Tue Apr 03, 2012 11:42 am

I just realized that I made a small change to the registers from table 4. I write the value $12 to register $00, instead of $01. With $01 the screen remains black.

Here's a copy of my bit file: main.bit. It should produce colorbars in NTSC format. On my PAL TV, I see them in B/W, which is what I would expect from the signal.

Edit: the bit file produces composite out. I haven't checked the other outputs, but it could be that they aren't working, because there are separate amplifiers and enable bits.

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Apr 03, 2012 12:00 pm

Right. I have enough info thanks to those waveforms you posted. I see the value $03, then the low for a write, then the ACK. I see the 3 ACK's. Now I understand I2C. It finally 'clicked'!

I don't see the ACK's on my board. I separated the short mentioned before. Troubleshooting... My SCL is right at 100kHz. I'm going to reflow the solder on the CS4954.

Arlet · Post by **Arlet** » Tue Apr 03, 2012 1:12 pm

Did you try the bit file ? It will be a simple test to check for hardware problems. You've tried the other bit file before, the one that generated the screen with the blue border, and black/white bars in varying widths. Since that one worked, I wouldn't expect a hardware problem at this point.

Edit: if you want, you can also send me your bit files, and I'll try them on my board to see if they work.

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Apr 03, 2012 2:14 pm

Ah you're right. It should work.
I've tried getting an ACK from the 1 DS1085 I have on the bus too. Nothing. So I went back to the original 65Org16. Still nothing, and the waveforms look exactly like the DS1085 datasheet!

I will modify my program for the original 65Org16 to send the following values in a loop: $00,$03,$01. Right now it waits for a keypress from the PS2 keyboard to send the data while running C'mon on the TFT. Give me a few minutes.

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Apr 03, 2012 2:41 pm

The 'ifdef' statements! I just realized I had been copying and pasting the cpu.v verilog file from my testbench for simulation right into my project folder. This must be it. Sec...

EDIT: Clarified file as cpu.v

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Apr 03, 2012 2:51 pm

That wasn't it. Sorry. I have a another task to complete that will take a few hours.

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Apr 03, 2012 9:26 pm

I apologize for having left as bruptly as I did. Family matter, no worries...

I came home, tested again with the latest .b core and a loop on my main TFT project top level schematic, with the 65Org16 software gutted except for your I2C software sending 3 bytes: $00, $03, $01. Then a $FFFF countdown delay and it all starts over. I am still seeing no ACKs. Had to use the sample function on my scope as there is no steady trigger.

Here is the top_level .bit file.

EDIT: This file server is much better. File is only available for 7 days though.
EDIT: This one is correct. Looking at it this morning I found a bne A, instead of a bne AA. Was looping into never never land. Signals are stable now. No ACKs.

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Apr 04, 2012 1:29 pm

I am really stuck here. Arlet, if your .bit project file outputs a good video signal this means my hardware is OK. I am seeing good signals on the scope for SCL and SDA, using my project file, which means the software and .b core are OK. So what possibilities are left for no ACK?

Arlet · Post by **Arlet** » Wed Apr 04, 2012 1:40 pm

I'll try your bit file tonight when I get back from work. Maybe that'll reveal something...

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Apr 04, 2012 4:00 pm

I have a feeling you will see what I am seeing.... Been doing some more testing.

I've run your I2C progam through M. Kowalski's simulator to try to get a feel for what is going on. And now something is clear to me that wasn't so clear before, i.e. why you were doing an ADC #$00. When sending a zero data, the last shift will set the carry flag and add a $01 to the Accumulator, sending SDA high. Which is not happening in my case. I have tested the carry on the .b core and it seems to be ok. I have a hunch that the carry is being set 1 cycle too late on the .b core. This probably means my decoding is not tight enough... And I can see right now a load_reg is being performed incorrectly on a CLC, and SEC. I will fix this and restest.

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Apr 04, 2012 4:55 pm

Oh, I also just realized you SEC and ROL 8x to get the carry set after 8 ROLs. In my case it is 16 ROLs. I must do 8 ROLs right after the SEC. Testing...

Arlet · Post by **Arlet** » Wed Apr 04, 2012 5:01 pm

Yes, I just tested your top level bit file, and it doesn't work on my board. Your SDA doesn't go back high after the 8th clock pulse. The I2C ACK means that the client device pulls the SDA down at the 9th clock, but that only works if the master lets it go back high first.

My code is a bit tricky. It shifts out 8 bits from the 8 bit data register, but then it shifts out a 9th bit from the same place. Because of this code in i2c_wrbyte:

Code: Select all

SEC
ROL data

the 9th bit is always a '1'. Because you have a 16 bit CPU, the SEC is not effective. Instead, at the top of the i2c_wrbyte routine, you should move the 8 data bits to the most significant 8 bits (shift left

, and then ORA #$0080 to make sure the 9th bit is set before entering the loop. The SEC instruction in the loop can be removed.

Arlet · Post by **Arlet** » Wed Apr 04, 2012 5:02 pm

ElEctric_EyE wrote:

Oh, I also just realized you SEC and ROL 8x to get the carry set after 8 ROLs. In my case it is 16 ROLs. I must do 8 ROLs right after the SEC. Testing...

No, if you do 8 ROLs, the entire data byte will be gone. You need to do 1 ROL per loop iteration, to shift out 1 bit at at time.

Arlet · Post by **Arlet** » Wed Apr 04, 2012 5:03 pm

ElEctric_EyE wrote:

EDIT: This file server is much better. File is only available for 7 days though.

You can also e-mail the file directly if you prefer.