AVR Freaks

If you reach an impasse using the Atmega5815, you might want to try an Attiny861. It is basically an Attiny85 with 8 more general purpose I/O pins.

I just started to interface an Attiny861 with an SD card using petit FatFS and have gotten pfsample files to talk to my PC using slightly modified versions of suart. I'm about to sort out the USI/spi interface and found that I have not defined the direction of its output pins correctly (the MISO/DO pin label was confusing).  You might want to add an LED to the CS line as shown in the picture in the file.

Alan

You might find the FAQ section of AVR Libc at http://www.nongnu.org/avr-libc//user-manual/FAQ.html , specifically http://www.nongnu.org/avr-libc//user-manual/FAQ.html#faq_reg_usage , very useful for many areas.  R24 is used to pass 8 bit function arguments to assembly code and to return an 8 bit value to the calling function. R25 & R24 are used for 16bit values  The second link has more info about register use.   If you look at Chan's assembly language code, you will see that he uses R24 and R25 a lot without saving their contents.

Alan

I am at the same step in the process of getting pff to work and have received the same response of rc=1 (STA_NOINIT according to pff.h).  I'm a little slower than you to pull out the logic analyzer because I'm trying to understand code flow and what is generating the response.  Needless to say, I'm quite interested in any solution you find. 

I started looking for the location where I might increase the wait time between InIdleState and the timeout but my (very preliminary assessment) is that the rc response seems to be caused by not recognizing the type of card so I was going to try a different card.  As a quick test last night, I pulled the SD card from the socket to see if I could get  a rc=2 (STA_NODISK) but did not.  However, I believe my socket can not detect when a card is present.

My next step is to pull out my scope and logic sniffer to make sure my SPI signals look reasonable.

Good luck.

BTW, I'm using a 2GByte card and chose to FAT16 in  the config file.  I exceed the .text memory size of the ATtiny861 if I choose FAT32 and a WRITE capability.  I did try FAT32 (and no WRIRE) but got the same initialization fail response code (rc = 1)

Now that is an interesting suggestion.  I have a ATmega328 on a development board that would allow me to build a Debug configuration and step through the C code.  Some of the assembly language routines provide USART and SPI services (via USI) that transfer single bytes.  So I should be able to wrap the UART and SPI hardware in the mega328 with functions of the same name.  

I'll take a look at the code again to see how isolated the assembly language USART and SPI functions are, how involved the mega328 wrappers might be, if the effort is worth it (which I think would be if I can get the debugger involved) and what other complications may arise from other function interactions. 

Quick question:

Will assembly language instructions that don't involve special registers of the tiny861 work in a mega328.   My experience with assembly language is a little dated going was back to the '70s with the Zilog Z80 in a hobby environment and a short stint with the RCA 1802 at work.

Thanks, Alan

P.S. Life is getting in the way so I'm not sure when I might be able to do the above.  Before that effort, I want to make sure the SPI interface of the tiny861 is active since I have the hardware set up.

Rooney,

I just re-read Chan's article about How to Use MMC/SD to learn what SPI mode to use and noticed his comment that the SD Card's DO line must have a pull up resistor attached or "some cards will fail initialization process".  I know that one fault of my SD socket module is that it does not relinquish control of the MISO line when the CS goes high.   I have not had time to check this condition on my hardware but thought you might want to try it.  I read somewhere that a 10K resistor should work - the output is open collector drain

Edit: its CMOS

Petit FF has a similar delay in avr_mmcp.c

	for (tmr = 10000; tmr && send_cmd(cmd, 0); tmr--) dly_100us();	/* Wait for leaving idle state */
	if (!tmr || send_cmd(CMD16, 512) != 0) {	/* Set R/W block length to 512 */
		ty = 0;
	}

ty is the card-type variable which is used to indicate success or failure in many steps of initialize.  At the end of the function, it is tested for non-zero and then returned

	CardType = ty;
	CS_HIGH();
	rcv_spi();

	return ty ? 0 : STA_NOINIT;

I struggled for years to interface a storage unit to a microcontroller.  I downloaded the code used by most developers here; ELM I believe.

But the triple combination of no comprehensive documentation on the ELM library, no systematic overview tutorial/documentation of the data/disk/SD/FAT storage process, and incomprehensible C compiler errors left me at total loss for the longest time.

I solved this by using the Arduino standardized UNO board coupled with a TFT shield that had an SD adapter mounted.  I bought a cheap 4Gig SD card and PC adapter.   I formatted the SD card on the PC and added the Adafruit Parrot demo BMP file.   Then I downloaded the simple examples for the SD library that is included with the Arduino IDE.   They compiled and ran successfully.   I was able to get the Adafruit parrot displayed on my TFT screen, by compiling the demo exactly as it was and by using same hardware as the demo (abet from a clone manufacturer).

Then I downloaded all the examples of SD card access that I could find on the web and studied/reviewed them.  I modified the simple demos and monitored the results.   I did do a brief review of all the code comprising the classes that went into the SD library.  But since << the code just worked >> I didn't spend a lot of time on it.  I spent the time instead developing the application.

I'm comfortable with my SD interfacing programming skills even though they are limited to the Arduino platform.  But since the Arduino is the cheapest, most well-documented, and most standardized AVR platform in the world,  I  <<don't care anymore>> that I can't understand all the messages above.  I can make cheap robust working programs that use SD cards, which is the kind that customers prefer to pay for.

  Obsession with obsolete microprocessor technical details is a 20th-century mental disorder.  What difference does it make if you can fit an SD interface into 8K of SRAM when the CPU with 80K of SRAM is selling for about the same price?

I am afflicted!  And also in the 21st century.

--Mike

Got the SPI interface to work last night in an isolated project. Wish I could tell you why it now works because I did not run an "as-is" test before moving the pin direction and state-setting statements into the init_spi() function.  Was surprised that the SCLK is running at 5MHz 4 MHz with a 8MHz CPU clock.  I use a MOSFET level shifter (from Sparkfun) and 6 inch leads to and from the shifter - not acceptable at 5 4MHz (lots of ringing at the card's socket module).  So before further tests, I plan to build a small adaptor for diodes between 5 volt microcontroller (want to eventually run at 20MHz) and 10k pull-up resistors to 3.3v on the card's socket module.

In addition to the xmit_spi() and rcv_spi() functions, I copied avr-mmcp.c with the initialization() function so that I can use the debugger on initialization().  The Debug configuration Hex file size is only 17% of the controller's flash size so I look forward to a more direct method of finding out what is wrong.

Edit: correct SPI clock speed.

Rooney,

I have a couple of questions about the code you are using.

1) Are you using the usi.S file beginning with:

I ask because I found the comments in xmit_spi() confusing (although you might not have because (I believe) you do not use the Universal Serial Interface hardware).

In the code:

at line 82, Chan refers to DI as the "bit to send".  That terminology is 'correct' if your reference for DI is at the SD Card side of the interface.  You'll notice that on line 84, he sets the DI pin high if in the previous instruction, sbrc, pin 7 of R24 is clear.  sbrc paraphrased is: skip the next instruction if the bit 7 in R24 is clear (logic 0). So if you have a 1 in the msb (bit 7) of the byte to be sent (R24), flow will continue to the next instruction and set (sbi -> set bit in IO register) DI to a 1 for output.

So my next question is:

2) Do you have the connection from "DI" (Pin PB2 of PORTB as assigned above or whatever pin and port you have assigned to PORT_DI) connected to the input (MOSI) of your SD Card module?

I suspect you probably have swapped the two SPI data pins by now but wanted to ask anyway.

Alan

BTW, Since I believe you said that you were learning assembly language, you might be interested in a expansion of assembly language comments as I tried to resolve my confusion (pls take it as guidance and not absolute truth)   And BTW, my assignments of DO and DI are from the viewpoint of the micro-controller.

You can find a list of these instructions at https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_instruction_list.html

Getting late so I hope I have not messed anything up.

Edit: found error in first picture, replaced it with correct version

Thanks for the reference to asmfunc.S.  Its code is the same as the code I had in mind. The reference to the Microchip article is a (nice) summary of multiple pages in Chan's website (i.e the Application Programmer's Interface and related info) combined with Microchip's assessment of what controllers might be used.

As far correct connections, it depends how you assigned the DI and DO pins in the #defines at the top of asmfunc.S.  I suspect you have correctly assigned DI define to the number 5 (PB5, MOSI), the DO define to 6 (PB6,  MISO) and the clock to 7 (PB7, SCK)  in your ATMega8515 or you would not have seen anything when using your logic analyzer.

I hope to get the Dragon and Dragon Lair set up today or tomorrow.  I need to change SPI pin assignments since at the present time, SPI signals might be affected by any load placed on the MOSI, MISO, and CLK pins while the debugger is attached. (If you remember, my SD Module does not tri-state the MISO pin when not selected.)  I realize the debugger uses only the reset pin, target power and ground but I really don't want to take a chance and am getting tired if pulling the programming cable after each change in code.

Hope you have a good day,

Alan

Rooney,

Got it working today in both the isolated project and the pfsample project.  Only slightly modified the usi.S file for clarity (now renamed susi.S because it is the software version that emulates USI hardware).  I attached the file "susi.S.zip"; it is not a zip file so just strip ".zip" from the extension and place it in your pfsample project.  All the function names inside the file are the same as the usi.S you are now using (and BTW, delete the usi.S file). You will have to modify the #defines at the beginning of that file to match your pin assignments but other than that, it should compile and work successfully.  In the attached software, the pin assigned to DO should connect to the MOSI pin on the SD module, DI connect to the MISO pin, CLK to CLK pin and CS to CS pin.

I believe my problem was in hardware.  As mentioned in the "SD Card 5v to 3.3v level shifting" thread, I found a problem with signal ringing and build a level shifter daughter board, to mount the Sparkfun level shifter, for the LCSoft SD Socket module.  I tested this combination with an interface tester (Bus Pirate) and confirmed that the SD Card could be initiated and that it replied successfully (read the boot record on the SD Card) to the Bus Pirate. So I now knew that the hardware worked.

I then took the software you are using in asmfunc.S, sightly modified xmit_spi() for clarily and confirmed that signals were present on their respective output pins and in correct order using a dual trace scope.  Last step was to connect the controller to the SD Card socket module.

Before connecting the Dragon, I tried the 'new' software with the hardware and received an rc=0 reply.  Taken back a bit, I copied (just) susi.S to the pfsample project, compiled and ran the project.  Disk Initialization and Mount Volume returned successfully as show below:

PFF test monitor
>?
 fi - Mount volume
 fo <file> - Open file
 fd - Dump 128 bytes of file data
 ft - Stream the file to console
 fe <ofs> - Move r/w ptr
 fw <len> <val> - Write data to file
 fp - Write console input to file
 fl [<path>] - Read directory
>di
rc=0
>fi
rc=0 FR_OK
>

I hope that you have success with that file also.

Alan

Added later: If operating correctly, the SD module and card should draw about 15ma more than the rest of your hardware.