View previous topic :: View next topic |
Author |
Message |
poesboes
Joined: 27 Jan 2009 Posts: 11 Location: Utrecht
|
Posted: Tue Apr 21, 2015 5:30 pm Post subject: Porting KokkeKat to XMEGA |
|
|
Hello Niclas,
First, thank you for sharing the KokkeKat library.
I'm currently trying to get it to work on an ATXMEGA256D3 and i have adapted the KokkeKat code for use with the xmega family. SPI support is a little bit different in Bascom AVR for xmega.
I have had no reply from the SD cards though. Test were done with one Canon SD 16Mb oldie and a SanDisk SD-HC 16GB.
Furthermore 3.3V is nice and steady, 5 x 100kOhm pull-ups present, neat PCB.
The initial SPI speed was set to 250kbps:
Config Spic = Hard , Data_order = Msb , Master = Yes , Mode = 0 , Clockdiv = Clk128 , Ss = None 'Clk128 @ 32MHz = 250kHz
Open "SPIC" For Binary as #10
In all subsequent code i replaced "SPIOUT" >> PRINT #10, .. and "SPIIN" >> INPUT #10 , ... (Both SPIIN and INPUT shift out $00's in Bascom)
The cards don't respond during sdinit:. Both SDstatus 9 and the DO line never changes from high state. (I.e. response $FF). Data and clock toward the card looks fine and the timing is solid. Cards work fine on Windows PC.
Do you have any suggestion?
Thanks!
Bas
PS Here's my settings:
' Developer switches:
' 1 = minimum detail (only make sure that the init is successful)
' 0 = full detail (return full detail if init is unsuccessful)
Const Sdinitdetail = 1
' 1 = FAT16/32 file system active
' 0 = FAT16/32 file system not active (only read and write raw sectors)
Const Sdfsactive = 1
' 1 = Use the FIND routine
' 0 = Don't use the FIND routine
Const Sdusefind = 0
' 1 = Enable Sdusefindstoreentry
' 0 = Don't enable Sdusefindstoreentry
Const Sdusefindstoreentry = 0
' 1 = Use Sddirlist
' 0 = Don't use Sddirlist
Const Sdusedirlist = 1 ' Use or don't use
Const Sddirlistarraysize = 12 ' If used, set the size of the array that holds the cluster numbers
' 1 = read
' 0 = not reading
Const Sdrmode = 1
' 2 = write unbuffered
' 1 = write buffered
' 0 = not writing
Const Sdwmode = 1
' 1 = Use Sdappend
' 0 = Don't use Sdappend
Const Sduseappend = 0
' 1 = Clear the unused end of the sector before writing it to the SD card
' 0 = Don't clear the unused end of the sector before writing it to the SD card
Const Sdcleartail = 0
' 1 = Use FAT32 fsinfo sector data
' 0 = Don't use FAT32 fsinfo sector
Const Sdusefsinfo = 1
' 1 = Use Long FileNames when reading
' 0 = Don't use Long FileNames when reading
Const Sduselfn = 0
' 1 = When using lfn, also support file name comparison
' 0 = When using lfn, don't support file name comparison
Const Sduselfncompare = 0
' 1 = Use wipe
' 0 = Don't use wipe
Const Sdusewipe = 0
' 1 = Use DIRLIST delete
' 0 = Don't use DIRLIST delete
Const Sdusedirlistdelete = 0
' 1 = Use the size info routine
' 0 = Don't use the size info routine
Const Sdusesizeinfo = 1
' 1 = Use the CRC7 function
' 0 = Don't use the CRC7 function
Const Sdusecrc7 = 0 ' This has no practical use in the library - use it if you want to add CRC7 checks yourself |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Tue Apr 21, 2015 8:12 pm Post subject: |
|
|
when using : Ss = None
take care that you set the SS pin to output mode before you configure the SPI. _________________ Mark |
|
Back to top |
|
|
poesboes
Joined: 27 Jan 2009 Posts: 11 Location: Utrecht
|
Posted: Wed Apr 22, 2015 12:05 pm Post subject: |
|
|
albertsm wrote: | when using : Ss = None
take care that you set the SS pin to output mode before you configure the SPI. |
Thanks Mark; and indeed i did that. Moreover i configured all SPIC lines following the 'help' instruction:
Quote: | The pins are configured before the SPI control register is set. If you do not use the AUTO mode, you must set the pin direction and state yourself before using the CONFIG SPI. The following table shows which pins you have to set when NOT using the AUTO mode.
(table listing MISO, MOSI, CLK and SS)
|
I just went back to have a look at the original initialization as used by KokkeKat for the MEGA:
{In main: $CRYSTAL = 8000000} Code: |
Config Spi = Hard , Interrupt = Off , Data Order = Msb , Master = Yes , Polarity = Low , Phase = 0 , Clockrate = 64 , Noss = 1 , Spiin = 255
'Spcr = &B010
Spiinit |
I missed out the explicit "SPIIN = 255"
I changed line 972 xmega.lib at _inputspivar: to change from default $00 clocked out at read to something else.
Change 'clr r24' >> 'ldi r24, &B11111111'
This did indeed change the state to 255 as required; but alas, still no valid &B0000_0001 response.
Changing my setup from 250kbps to 125kbps -as used in the KokkeKat example- also did not generate a response.
One other thing i noticed was that when conducting a PRINT to SPIC, the MOSI line idles to low, even when $FF is sent. I think with SPIOUT the MOSI line remained at the last bit state?
KokkeKat uses 74 '$FF byte' sends to generate clock cycles toward the SD, before SS is lowered. I don't know if MOSI is to be kept high; with PRINT it isn't.. it switches to low state after every byte sent.
>>Can one change the idle state of MOSI after a PRINT?<<
(BTW comment in KokkeKat states 'at least 74 clock cycles'. Sending 74 bytes might be a bit much: 74 * 8 = 592 clocks)
Best wishes,
Bas
PS
(BTW, this is the full initialization i used for SPIC :
Code: | ' SPI declaration:
Config Portc.4 = Output ' The !SS pin can only be used as an output in SPI hardware master mode)
Sd_cs Alias Portc.4
set Sd_cs
Config Portc.5 = Output
Sd_di Alias Portc.5 ' MOSI None-Auto SS needs ALL SPI ports to be configured
Config Portc.7 = Output
Sd_clk Alias Portc.7 ' Clock
Config Portc.6 = Input
Sd_do Alias Portc.6 ' MISO
Config Spic = Hard , Data_order = Msb , Master = Yes , Mode = 0 , Clockdiv = Clk128 , Ss = None 'Adapted BvD 14-04-2015. Clk128 @ 32MHz = 250kHz
Open "SPIC" For Binary as #10 |
) |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Wed Apr 22, 2015 9:11 pm Post subject: |
|
|
sending 10 bytes is indeed sufficient. maybe you can show your circuit?
Quote: | I think with SPIOUT the MOSI line remained at the last bit state |
the mode you chose has impact on this. have a look in the pdf at the various modes.
maybe you need mode 1?
also, how do you create those pulses? with a for next loop?
Maybe you can send an array() of 10 bytes instead. this also means that you do not need to alter the lib. _________________ Mark |
|
Back to top |
|
|
poesboes
Joined: 27 Jan 2009 Posts: 11 Location: Utrecht
|
Posted: Thu Apr 23, 2015 11:18 am Post subject: |
|
|
Thanks again for thinking along Mark; much appreciated!
albertsm wrote: | sending 10 bytes is indeed sufficient. maybe you can show your circuit? |
Testing with sending out 10 bytes had no response either; there's a nice 80 pulse from clock, but no reply to the subsequent CMD0 reset. (Tested with two SD cards.)
Please find attached the main schematic of my project.
Quote: | I think with SPIOUT the MOSI line remained at the last bit state |
albertsm wrote: | the mode you chose has impact on this. have a look in the pdf at the various modes.
maybe you need mode 1? |
I have not gone too deep into the KokkeKat Bascom code, but i changed the mega initialization to xmega code. The mega initialization has 'Polarity = Low, Phase = 0' which i figured to be equal to Mode 0?
What is troublesome is that the SD protocol while using SPI is a little different from ordinary SPI. To start with, you need to send the 74 clocks with CS not-asserted to get the SD going. (Which is a no-no in any regular SPI application.)
albertsm wrote: | also, how do you create those pulses? with a for next loop?
Maybe you can send an array() of 10 bytes instead. this also means that you do not need to alter the lib. |
It's handled in the KokkeKat library (KokkeKat_FAT-free_SD_lib_code.bas); here's the relevant section:
Code: | Sdinit:
Sdstatus = 9 ' Minimum initialization detail unspecified error 2
Set Sd_cs ' Pull CS high
Sdcommand = &HFF ' Send at least 74 clock cycles with cs high
For Sdtempb = 1 To 74
Gosub Sdcommand1
Next Sdtempb
Reset Sd_cs
Gosub Sdcommand1 ' Send 8 additional clock cycles with cs low
Sdcommand = &H40 ' Send CMD0: &H40 &H00 &H00 &H00 &H00 &H95
Gosub Sdcommand1
Sdcommand = &H00
Gosub Sdcommand1
Gosub Sdcommand1
Gosub Sdcommand1
Gosub Sdcommand1
Sdcommand = &H95
Gosub Sdcommand1
Gosub Sdresponseloop
.....
|
and with Sdcommand1 defined as:
Code: |
'-------------------------------------------------------------------------------
Sdcommand1:
'Spiout Sdcommand , 1
Print #10 , Sdcommand ; 1 'BvD: Changed 14-04-2015 for xmega use
Return
|
And indeed, it is not good practice to alter the library code for xmega.lib. Might be good to have a replacement statement for SPImove and/or have a parameter in Config SPIx to set the code to be clocked out on using the Input statement; like with the mega initialization (like the 'SPIIN = 255' statement).
Are there alternative SD card routines for working with xmega? I don't think AVR-DOS has xmega support, has it?
Best thanks!
Bas
[/code][/quote] |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Thu Apr 23, 2015 12:18 pm Post subject: |
|
|
- avr-dos does support xmega. and it supports sd and sdhc cards. 11 bit and 32 bit fat.
have a look in the MMCSD_HC.LIB from avr-dos. it might have a clue on how you can change the code.
- yes it is odd that MMC/SD uses spi like that. I had problems with a board which had a driver chip using CS to put the board in hi-z. It should also work when you make CS low. (in the lib you find code for SHIELD)
- i wonder if you tried using a mega with the same SD cards? _________________ Mark |
|
Back to top |
|
|
poesboes
Joined: 27 Jan 2009 Posts: 11 Location: Utrecht
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
|
|