[Ack]v1.40..2.50: Help on MMC library, still some issues

[Dany]

Addendum: most of the issues were corrected in v2.50. Only points 1 and 3 are still there.


Hi, I just started using MMC/SD and I notices something in the help:
In the helptext for the MMC libary there is a code example (program "MMC_Test") at the end of it. I have a few remarks about that:

1. The variable "SectorNo" is never initialised before it is used, perhaps this can be corrected in the help? Thanks in advance.

2. I had to (with a 2GB SD card from EMTEC, speed upto 60x) use the following SPI initialisation:

Code: Select all

SPI1_Init_Advanced(_SPI_MASTER_OSC_DIV4, _SPI_DATA_SAMPLE_MIDDLE, _SPI_CLK_IDLE_HIGH, _SPI_LOW_2_HIGH);

in stead of

Code: Select all

SPI1_Init_Advanced(_SPI_MASTER_OSC_DIV16, _SPI_DATA_SAMPLE_MIDDLE, _SPI_CLK_IDLE_LOW, _SPI_LOW_2_HIGH);

With the initialisation from the example it did work not very well: much errors, especially "content" errors, and after a while the card blocked completely.
The only thing I had to change was "_SPI_CLK_IDLE_LOW" into "_SPI_CLK_IDLE_HIGH".
As you can see I can even use the highest clock frequency (...DIV4 with a 40Mhz CPU clock speed) with this new setting.

I work with the "MMC/SD CARD Proto".

Addendum: apparently setting AN4 to digital causes this problem if the AN4 pin (= RA5) is not set to output or is floating as input. Thanks yo2lio for the solution. So: "_SPI_CLK_IDLE_LOW" is OK provided AN4(RA5) is not floating.


3. The type of parameter for procedure "UART_Write_Line" should be (I think) "var uart_text : array[255] of byte" (or "var uart_text : string[255]"), the same as for routine "UART1_Write_Text", now it is simply a byte var parameter.

Code: Select all

procedure UART_Write_Line( var uart_text : byte ); // <----
  begin
    UART1_Write_Text(uart_text); // <----
    ...

Then a few remarks on the help content itself:

4. In mmc_init the help says:

Parameters:
port: chip select signal port address.
cspin: chip select pin.

The parameters (of the function) are not there. In stead global variables are used.

Fixed in v2.50

5. In mmc_read_sector the help says:

Parameters:
sector: MMC/SD card sector to be read.
data: buffer of minimum 512 bytes in length for data storage.

The "data" parameter has an other name in the prototype (same in mmc_write_sector also).

Fixed in v2.50

6. In mmc_fat_quickformat the help says:

Parameters:
port: chip select signal port address.
pin: chip select pin.
mmc_fat_label:

Port and Pin are no longer there, they have been replaced by global variables.

Fixed in v2.50

Keep up the good work!

Thanks for the corrections done in v2.50!

[srdjan]

2: We did not experience such behavior, it will be investigated.
1, 3, 4, 5, 6: will be checked and fixed if necessary.
Thanks.

[Dany]

2: We did not experience such behavior, it will be investigated.
1, 3, 4, 5, 6: will be checked and fixed if necessary.
Thanks.

Thanks SrdJan!

[Dany]

Hi SrdJan,

Regarding point 2:

The only thing I had to change was "_SPI_CLK_IDLE_LOW" into "_SPI_CLK_IDLE_HIGH".

2: We did not experience such behavior, it will be investigated.

I discovered that SPI goes wrong with "_SPI_CLK_IDLE_LOW" when I assign $0F to ADCON1. In general, as soon as I try to switch AN4 to digital (so all values from $0B onwards), SPI needs "_SPI_CLK_IDLE_HIGH" in stead of "_SPI_CLK_IDLE_LOW" (on P18F2620 in SPI master mode, where AN4 is the same pin as SS, an SPI slave pin).

I can not find in the datasheet why this should be the case.

Important:
In the help example "program MMC_Test", the statement

Code: Select all

ADCON1 := ADCON1 or 0x0F;                  // Configure AN pins as digital

is present which causes above described behaviour.

So, I think you can ignore point 2, it works with "_SPI_CLK_IDLE_LOW" (provided... see above).

Thanks!

[srdjan]

Hi,

So, I think you can ignore point 2, it works with "_SPI_CLK_IDLE_LOW" (provided... see above).
Thanks!

Thank you for the report.

[yo2lio]

Dany, I had the same problem with PIC18F2620, in the past with my UDP bootloader ENC28J60. (my SPI library and my ENC library)

This problem was solved, I don't remember exactly how, I kept SS pin LOW or HIGH via 4k7 resistor.

Please try mikroe example again with pull up or pull down resistor on SS pin.

[Dany]

Dany, I had the same problem with PIC18F2620, in the past with my UDP bootloader ENC28J60. (my SPI library and my ENC library)

This problem was solved, I don't remember exactly how, I kept SS pin LOW or HIGH via 4k7 resistor.

Please try mikroe example again with pull up or pull down resistor on SS pin.

Thanks, I will.

[Dany]

Dany, I had the same problem with PIC18F2620, in the past with my UDP bootloader ENC28J60. (my SPI library and my ENC library)

This problem was solved, I don't remember exactly how, I kept SS pin LOW or HIGH via 4k7 resistor.

Please try mikroe example again with pull up or pull down resistor on SS pin.

Thanks, I will.

Hi Yo2Lio, a pullup or pulldown resistor (I used 1K0) on the SS pin is indeed the solution!
Good to know. Thanks!

Added later: also setting the PortA.5 (= the SS pin) direction to output is a solution. No pullup/down resistor needed in this case.

[yo2lio]

Hi Yo2Lio, a pullup or pulldown resistor (I used 1K0) on the SS pin is indeed the solution!
Good to know. Thanks!

Added later: also setting the PortA.5 (= the SS pin) direction to output is a solution. No pullup/down resistor needed in this case.

It's a silicon BUG I think !

[Dany]

It's a silicon BUG I think !

Seems it is, but I can not find it in any "errata" document. Also some users on the Microchip forum report this problem (for another PIC however), see:
http://www.microchip.com/forums/tm.aspx?m=369346.