6502.org
http://forum.6502.org/

65SPI confusion
http://forum.6502.org/viewtopic.php?f=10&t=7748
Page 1 of 1

Author:  speculatrix [ Sun Sep 10, 2023 10:06 am ]
Post subject:  65SPI confusion

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.

Author:  speculatrix [ Sun Sep 10, 2023 11:50 am ]
Post subject:  Re: 65SPI confusion

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!

Author:  BigEd [ Sun Sep 10, 2023 1:04 pm ]
Post subject:  Re: 65SPI confusion

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

Author:  GARTHWILSON [ Sun Sep 10, 2023 4:21 pm ]
Post subject:  Re: 65SPI confusion

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.

Author:  speculatrix [ Sun Sep 10, 2023 4:47 pm ]
Post subject:  Re: 65SPI confusion

GARTHWILSON wrote:


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

Author:  8BIT [ Sun Sep 10, 2023 5:51 pm ]
Post subject:  Re: 65SPI confusion

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

Author:  speculatrix [ Sun Sep 10, 2023 6:39 pm ]
Post subject:  Re: 65SPI confusion

8BIT wrote:
Best wishes for you project!Daryl


Thanks Daryl. And thanks for 65SPI!

Author:  greghol [ Tue Sep 12, 2023 6:36 am ]
Post subject:  Re: 65SPI confusion

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

Author:  speculatrix [ Wed Sep 13, 2023 1:24 pm ]
Post subject:  Re: 65SPI confusion

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.

Attachment:
SPI_read.png
SPI_read.png [ 76.27 KiB | Viewed 10769 times ]


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:
\ ------------------------------------------------------------------------------
\ ---  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:
.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

Author:  8BIT [ Wed Sep 13, 2023 3:08 pm ]
Post subject:  Re: 65SPI confusion

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:
  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

Author:  speculatrix [ Wed Sep 13, 2023 4:52 pm ]
Post subject:  Re: 65SPI confusion

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.

Author:  8BIT [ Wed Sep 13, 2023 5:07 pm ]
Post subject:  Re: 65SPI confusion

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

Page 1 of 1 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/