65SPI confusion

[speculatrix]

I’ve created an SPI board for my 6502 machine, based around Daryl’s (8BIT’s) 65SPI.

And the board doesn’t work (or rather it partially works). I’m starting to suspect that this is the result of a stupid misunderstanding on my part. So I just want to check that I’ve made the mistake that I think I have.

When one of the Slave Select lines is selected (ie, it’s bit is high in the register) does the output go high or low?

I assumed low because, well, pretty much every SPI device’s CS input that I’ve encountered is active low. But my logic analyser is telling me the opposite. Just need a sanity check.

If the answer is indeed that the line goes high, then I’m either going to have to respin the board to include an inverter chip or somehow hack 65SPI to invert the logic.

If the answer is that the line goes low, I’m going to have to have a serious talk with myself about my logic analyser technique.

[speculatrix]

It’s only just occurred to me that I can invert the logic by what values I write to the register.

Doh! It would be nice to be clever one day.

Update: Changed the logic in my code - now the board works. Phew!

[BigEd]

A good result! Sometimes explaining the problem gets you half-way to realising what the solution is.

[GARTHWILSON]

BigEd wrote:

Sometimes explaining the problem gets you half-way to realising what the solution is.

rubber-duck debugging:  https://en.wikipedia.org/wiki/Rubber_duck_debugging
It's also a good reason to comment code as if explaining it to someone who was not involved in the development in any way including choosing why certain things were done the way they were, because it sometimes causes us to find problems that haven't even shown up yet.

[speculatrix]

GARTHWILSON wrote:

rubber-duck debugging:  https://en.wikipedia.org/wiki/Rubber_duck_debugging

I’d not heard of that before. Off to Amazon to order a rubber duck…

[8BIT]

Glad you figured it out. I should probably add a little more to the manual about using the SS register. My intent was to have it emulate a 74_373 latch and let the user control it as he wishes. I do use the /RES input to set all the outputs of the SS register to 1, which deselects all active-low devices.

Best wishes for you project!

Daryl

[speculatrix]

8BIT wrote:

Best wishes for you project!Daryl

Thanks Daryl. And thanks for 65SPI!

[greghol]

Yep, A lot of SS lines are just output ports on many SPI controllers. The programmer keeps them de-asserted until needed for transfers. I'm currently using a Microchip (Actel lineage) Igloo2 FPGA at work and the internal SPI controller is a hard block device connected to an AHB bus. The SS logic is controlled in a similar manor and is controlled over the AHB bus but is just a simple output port for its SS.

Greg

[speculatrix]

Okay, I'm afraid I have more problems, and this one is really driving me nuts.

My new plug-in board has serial battery-backed RAM, an RTC (DS3234) and SD card drive. I prototyped these devices with an Arduino, to get to know all the various registers etc.

The SRAM is working fine now, so I'm confident that some of my basic routines are up to snuff. But...

I'm having a weird problem with the RTC. And it seems to be to do with reading registers. To see what I mean, I've written a program that writes to a register and then reads it back. That's all. And, according to my logic analyser, it's working - except that I get the wrong value back.

I'm writing the value $13. Here's what the exchange looks like when I try to read the register.

As you can see, $13 is indeed being returned. But reading the SPI65 data register gives me $89. Weirdly, $13 and $89 are not dissimilar:

$13 = 00010011
$89 = 10001001

If you take $89 and rotate left (taking bit 7 to bit 0) you get $13. So it feels like I'm just one bit out of position.

The read function consists of putting the register number in A and then calling OSSPIEXCH twice. That function indirects to:

Code: Select all

\ ------------------------------------------------------------------------------
\ ---  SPI_EXCHANGE_BYTE
\ ---  Implements: OSSPIEXCH
\ ------------------------------------------------------------------------------
\ ON ENTRY: Byte to send should be in A
\ ON EXIT : Returned byte is in A
.spi_exchange_byte	   ; Sends & receives a byte. Byte value should be in A
  sta SPI_DATA_REG		; Write to Data Reg
.spi_wait_for_tc	  	; Wait for transfer
  bit SPI_STAT_REG		; Run BIT on Status Reg. If TC set, N flag will be set
  bpl spi_wait_for_tc	; If positive, bit 7 not set yet
  lda SPI_DATA_REG		; Read incoming byte. Clears TC flag
  rts

So, with $01 in A, I call that function and get $FF back. Then I immediately call the function again. This time $FF is in A because that was left over from the previous call. I get back $13 but A contains $89.

This is on a 1MHz 65C02 machine, so I'm not quite pushing the boundaries of speed here.

Any thoughts? I've tried slowing things down by putting some NOPs between the first exchange (sending the register number) and the second (getting the value back) but to no avail. I'm sure I'm doing something obviously stupid but can't see what.

[EDIT] Thought it would be useful to show the read register routine:

Code: Select all

.rtc_read_reg
  pha                               ; Save register number for later
  lda SPI_CURR_DEV                  ; Contents of this location previously set to %01111111
  sta SPI_DEV_SEL                   ; $BF02 - SPI SS register
  stz SPI_DATA_REG                  ; $BF00 : to clear TC
  pla                               ; Get register number back
  jsr OSSPIEXCH			                ; Selects the reg
  jsr OSSPIEXCH			                ; Register value returned in A
  ldx #SPI_DEV_NONE                 ; Constant with value %11111111
  stx SPI_DEV_SEL                   ; $BF02 - SPI SS register
  rts

[8BIT]

Two observations. The DS3234 datasheet shows SPI Mode 1 and 3 are supported. Are you using one of those modes? using the wrong mode sometimes results in data being misaligned.

Next, the

Code: Select all

  stz SPI_DATA_REG                  ; $BF00 : to clear TC

command is not needed and may be the problem. Writing any value to the Data register starts a data shift sequence. When you call OSSPIEXCH, the first action is to write the SPI data register which starts another cycle (on top of the first write). Try removing this line. If you feel you have to clear the TC register, do a read of the SPI Data register vs. a write. Either resets the TC flag and a read will not start a new sequence, unless the FRX bit is set in the control register.

Let me know if neither of these fixes your issue.

Daryl

[speculatrix]

8BIT wrote:

Two observations. The DS3234 datasheet shows SPI Mode 1 and 3 are supported. Are you using one of those modes? using the wrong mode sometimes results in data being misaligned.

I could have sworn I was using mode 0 with the C code on the Arduino. In fact, I was bit-banging the whole thing - I wanted to avoid libraries because the intent was to learn. Clearly, using that crude approach somehow allowed me to get away with it. Anyway, I switched to mode 3 and now it works.

Thanks for the help.

[8BIT]

I'm glad to hear it was a simple fix. be sure to adjust your code for the other observation as well.

best wishes!
Daryl