Post by thread:[PIC] Trouble using a SPI Atmel EEPROM with 16F689

part 1 1600 bytes content-type:text/plain; charset=us-asciiHi everyone, This is my first time using SPI and I'm having some problems. I think that I have the MSSP module configured correctly to Mode 0,0 in order to communicate with an AT25640A serial eeprom. My main program currently attempts to do this: 1. read and display the eeprom status register. 2. send the write enable instruction 3. clear all bits in the status register. 4. read and display the eeprom status register again. 5. write 0x55 to the first byte in the eeprom 6. read the first byte and display the value. I'm displaying the output by sending the info over a serial link and the code that does this is fairly well tested. The value that is always printed for the status register is 0x05 and this is unusual since it means that a write is in progress that that a quarter of the device is write protected. The same value is always printed in steps 1 and 4. The value displayed in step 6 is always 0x00 when it should be 0x55. I've attached a zip file that contains the code and a schematic. The code is broken into modules and commented. If anyone has ideas I would appreciate your help. Also, on Microchip's site, I found a PDF file named "spimpol.readme.pdf" describing some software called the "SPI Master Library Module". I've been reading every bit of SPI related source code I could find, wouldn't it be great to look at this module! Unfortunately, the only information I can find is the PDF file. Even google was of no help. :( If anyone can point me to example PIC assembly code for the Atmel eeproms I would be greatful. Thanks for any help. Matthew part 2 22196 bytes content-type:application/x-zip-compressed (decode) part 3 35 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit)

I've done some more debugging and I have isolated the problem somewhat. I removed the EEPROM and tied the PIC's SDI line to ground. I expected the debug output to change to only 0x00, but it didn't. The value reported for the status read was still 0x05. I've now noticed that this is the value of the status read instruction, but this clue hasn't helped me yet. Oh, I also correctly disable the comparator outputs now... So, why does the spi_rx_data contain 0x05 after calling spi_read_eeprom_status and not zero? Thanks. Matthew main movlw '1' ; A debug prefix. call transmitw movlw ':' call transmitw call spi_read_eeprom_status ; Read and display the status value. banksel spi_rx_data movf spi_rx_data, W call hex_debug ; ; The following routines are in spi_eeprom.asm ; ; Send a read status instuction to the eeprom and return the status value in ; the spi_rx_data byte. ; spi_read_eeprom_status enable_cs banksel spi_tx_data movlw READ_STATUS_INST movwf spi_tx_data ; The first shift sends the instruction. Ignore the received data. call spi_shift_data call spi_shift_data ; Now spi_rx_data contains the status value. nop ; A delay to help meet the hold time. disable_cs return ; This routine performs two functions. Given a value in spi_tx_data that value is ; transmitted. The byte received during the transmission is saved in ; spi_rx_data. ; ; spi_shift_data banksel spi_tx_data movf spi_tx_data, W banksel SSPBUF movwf SSPBUF banksel SSPSTAT spi_shift_wait btfss SSPSTAT, BF ; Wait until data reception has finished. banksel SSPBUF movf SSPBUF, W banksel spi_rx_data movwf spi_rx_data return

Hi, spi_shift_wait btfss SSPSTAT, BF ; Wait until data reception has finished. banksel SSPBUF I think you missing a GOTO here? Tamas On Fri, Jun 6, 2008 at 11:13 PM, Matthew Miller <spam_OUTnamiller2TakeThisOuTnaxs.net> wrote: {Quote hidden}> I've done some more debugging and I have isolated the problem somewhat. I > removed the EEPROM and tied the PIC's SDI line to ground. I expected the > debug output to change to only 0x00, but it didn't. The value reported for > the status read was still 0x05. I've now noticed that this is the value of > the status read instruction, but this clue hasn't helped me yet. Oh, I also > correctly disable the comparator outputs now... > > So, why does the spi_rx_data contain 0x05 after calling > spi_read_eeprom_status and not zero? > > Thanks. Matthew > > > main > movlw '1' ; A debug prefix. > call transmitw > movlw ':' > call transmitw > > call spi_read_eeprom_status ; Read and display the status value. > banksel spi_rx_data > movf spi_rx_data, W > call hex_debug > > > ; > ; The following routines are in spi_eeprom.asm > ; > > > ; Send a read status instuction to the eeprom and return the status value > in > ; the spi_rx_data byte. > ; > spi_read_eeprom_status > enable_cs > > banksel spi_tx_data > movlw READ_STATUS_INST > movwf spi_tx_data > > ; The first shift sends the instruction. Ignore the received data. > call spi_shift_data > call spi_shift_data ; Now spi_rx_data contains the status value. > > nop ; A delay to help meet the hold time. > disable_cs > return > > > ; This routine performs two functions. Given a value in spi_tx_data that > value is > ; transmitted. The byte received during the transmission is saved in > ; spi_rx_data. > ; > ; > spi_shift_data > banksel spi_tx_data > movf spi_tx_data, W > banksel SSPBUF > movwf SSPBUF > > banksel SSPSTAT > spi_shift_wait > btfss SSPSTAT, BF ; Wait until data reception has finished. > > banksel SSPBUF > movf SSPBUF, W > banksel spi_rx_data > movwf spi_rx_data > return > > -

On Fri, Jun 06, 2008 at 11:24:14PM +0100, Tamas Rudnai wrote: > Hi, > > spi_shift_wait > btfss SSPSTAT, BF ; Wait until data reception has finished. > > banksel SSPBUF > > I think you missing a GOTO here? Thank you. I have a difficulty about looking at code with fresh set of eyes; it is so easy for me to over lookig things. Thank you so much for spotting this! :) I really wish that I didn't post my sillier mistakes to the PIClist! But I'm glad you folks are so helpful. Matthew

Never mind, it happens all the time with me too :-) Regards, Tamas On Fri, Jun 6, 2008 at 11:40 PM, Matthew Miller <.....namiller2KILLspam@spam@naxs.net> wrote: {Quote hidden}> On Fri, Jun 06, 2008 at 11:24:14PM +0100, Tamas Rudnai wrote: > > Hi, > > > > spi_shift_wait > > btfss SSPSTAT, BF ; Wait until data reception has finished. > > > > banksel SSPBUF > > > > I think you missing a GOTO here? > > Thank you. I have a difficulty about looking at code with fresh set of > eyes; it is so easy for me to over lookig things. Thank you so much for > spotting this! :) > > I really wish that I didn't post my sillier mistakes to the PIClist! But > I'm > glad you folks are so helpful. > > Matthew > -

> I really wish that I didn't post my sillier mistakes to the PIClist! But > I'm glad you folks are so helpful I could tell you how much time I spent on a silly mistake yesterday, but I'm not going to. My code has two entry points from one of several external devices. The entry point depends on timing. Let's just say I was looking for a bug at the wrong entry point for some considerable time before the inevitable "Oh for Goodness Sake" moment. Which annoyingly I had at 3am as I put my head on the pillow. But I slept well because I knew exactly what the problem was and, sho' nuff, fixed right after the first cuppa this morning with a stroke of the keyboard It's extraordinarily difficult sometimes to distance your sleuthing process from code when it doesn't work and I fully empathise

On Sat, Jun 07, 2008 at 12:53:35PM +1200, Jinx wrote: > > I could tell you how much time I spent on a silly mistake yesterday, > but I'm not going to. My code has two entry points from one of > several external devices. The entry point depends on timing. Let's > just say I was looking for a bug at the wrong entry point for some > considerable time before the inevitable "Oh for Goodness Sake" > moment. Which annoyingly I had at 3am as I put my head on the > pillow. But I slept well because I knew exactly what the problem > was and, sho' nuff, fixed right after the first cuppa this morning with > a stroke of the keyboard > > It's extraordinarily difficult sometimes to distance your sleuthing > process from code when it doesn't work and I fully empathise Thanks Jinx and Tamas! I envy people here that work with a group of coworkers they can bounce ideas off of. I'm a hobbyist and well, there's just me. This current project is for my summer job though, so I'm very glad to have this problem solved! Thanks! Matthew

> I envy people here that work with a group of co-workers they > can bounce ideas off of. I'm a hobbyist and well, there's > just me There's just me here too. We're alone together. Aaaaaahhh. I don't think I've ever met anyone who hasn't said "Oh, lawks, I see what I've done", so you're in the company of ... everybody. Well, everybody who says "lawks" anyway Mistakes I don't mind too much. In some ways it's quite a good learning lesson and often it forces you to have either/both a mind/ code clean-up. I should be grateful for the small mercy of anything (expensive or awkward to replace) not going up in smoke for a while. That, I don't like

2008/6/7 Jinx <joecolquittKILLspamclear.net.nz>: > Mistakes I don't mind too much. In some ways it's quite a good > learning lesson and often it forces you to have either/both a mind/ > code clean-up. I should be grateful for the small mercy of anything > (expensive or awkward to replace) not going up in smoke for a > while. That, I don't like I agree. And it's for the same reason I do not let the spell checker correct misspelt words; rather I exit the checker, direct the cursor to the word and manually correct it. This way I will atleast type it right and will have a greater chance of learning its spelling, instead of just thinking "oh, it was 'bollocks' instead of 'ballocks'". -- - Rikard - http://bos.hack.org/cv/

At 12:26 AM 6/7/2008, you wrote: > > I envy people here that work with a group of co-workers they > > can bounce ideas off of. I'm a hobbyist and well, there's > > just me > >There's just me here too. We're alone together. Aaaaaahhh. I >don't think I've ever met anyone who hasn't said "Oh, lawks, >I see what I've done", so you're in the company of ... everybody. >Well, everybody who says "lawks" anyway http://en.wiktionary.org/wiki/lawks http://www.bartleby.com/309/107.html Sounds like something one would put on a bagel and/or serve with capers. >Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" .....speffKILLspam.....interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com

Rikard Bosnjakovic wrote: > I agree. And it's for the same reason I do not let the spell checker > correct misspelt words; rather I exit the checker, direct the cursor > to the word and manually correct it. This way I will atleast type it > right and will have a greater chance of learning its spelling, instead > of just thinking "oh, it was 'bollocks' instead of 'ballocks'". > > Doesn't look like you would have been wrong :) Wikipedia: [[bollocks]]:(vulgar; originally '''ballocks''', colloquially also spelled as ''bollox'')

Jinx wrote: > I wrote - > > >> I should be grateful for the small mercy of anything not going up >> in smoke for a while. That, I don't like >> > > Days Without A Mishap - 0 > > I accidentally put an alkaline in the charger (looks very similar to > the NiMH I meant to charge). Go off with quite a pop don't they. > Hit the wall on the other side of the room > > I had better try that just so I will recognize the phenomenon when it should occur...