[PATCH] Fix avr32 MMCFS on EVK1100 and MIZAR32

[Martin Guy]

Problem: If BUILD_MMCFS is enabled on EVK1100 or MIZAR32, the
interpreter can be compiler but does not start

Reason: MMCFS was never finished in AVR32, and hangs in a while(some
SPI register)

Diagnosis and problem resolution are by Nuccio Raciti.
I've just tested his patches for EVK1100, added and tested Mizar32
support, added evk1101 support (untested).
With this patch, BUILD_MMCFS is enabled by default for EVK1100 but not
for MIZAR32 due to code size contraints and not for EVK1101 as I can
only build, not test, that platform.

   M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Hi,

On Tue, Dec 14, 2010 at 8:16 PM, Martin Guy <[hidden email]> wrote:

> Problem: If BUILD_MMCFS is enabled on EVK1100 or MIZAR32, the
> interpreter can be compiler but does not start
>
> Reason: MMCFS was never finished in AVR32, and hangs in a while(some
> SPI register)
>
> Diagnosis and problem resolution are by Nuccio Raciti.
> I've just tested his patches for EVK1100, added and tested Mizar32
> support, added evk1101 support (untested).
> With this patch, BUILD_MMCFS is enabled by default for EVK1100 but not
> for MIZAR32 due to code size contraints and not for EVK1101 as I can
> only build, not test, that platform.

Thanks. I applied your patch but only partially. The problem is that
you changed the platform_pio_op operations relative to the SS pin in
src/elua_mmc.c to platform_spi_select calls and Atmel CPUs are the
only eLua CPUs that have a way of setting the SPI SS pin using the SPI
interface directly (not via usual PIO operations), thus your patch
broke MMC support on all the other platforms. This is why the
platform_spi_select function was a candidate of the functions to be
removed from the platform interface for a while now (it could still be
used by the means of a platform-specific module). Of course you
couldn't have known this. I guess the proper way to handle this would
be to make the SELECT and DESELECT call platform interface functions
specific to the MMC module support. I'll work on this. Until this is
ready the trunk version of elua_mmc.c won't work properly for Atmel
CPUs.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On Fri, Dec 17, 2010 at 12:03 AM, Bogdan Marinescu
<[hidden email]> wrote:

> On Tue, Dec 14, 2010 at 8:16 PM, Martin Guy <[hidden email]> wrote:
>> Diagnosis and problem resolution are by Nuccio Raciti.
>> I've just tested his patches for EVK1100, added and tested Mizar32
>> support, added evk1101 support (untested).
>> With this patch, BUILD_MMCFS is enabled by default for EVK1100 but not
>> for MIZAR32 due to code size contraints and not for EVK1101 as I can
>> only build, not test, that platform.
>
> Thanks. I applied your patch but only partially. The problem is that
> you changed the platform_pio_op operations relative to the SS pin in
> src/elua_mmc.c to platform_spi_select calls and Atmel CPUs are the
> only eLua CPUs that have a way of setting the SPI SS pin using the SPI
> interface directly (not via usual PIO operations), thus your patch
> broke MMC support on all the other platforms. This is why the
> platform_spi_select function was a candidate of the functions to be
> removed from the platform interface for a while now (it could still be
> used by the means of a platform-specific module). Of course you
> couldn't have known this. I guess the proper way to handle this would
> be to make the SELECT and DESELECT call platform interface functions
> specific to the MMC module support. I'll work on this. Until this is
> ready the trunk version of elua_mmc.c won't work properly for Atmel
> CPUs.

Thanks.

For what it's worth, current svn head (r863) seems to include the
changes that break MMCFS on other platforms, leaving:

// asserts the CS pin to the card
static
void SELECT (void)
{
  platform_pio_op( MMCFS_CS_PORT , ( ( u32 ) 1 << MMCFS_CS_PIN ),
PLATFORM_IO_PIN_CLEAR );
        //platform_spi_select( MMCFS_SPI_NUM, PLATFORM_SPI_SELECT_ON
); // select sd card pin
}

now only the tiny attached patch is needed to make MMCFS work on
Mizar32 and EVK1100 (and EVK1101 if we can test it), defining
MMCFS_CS_{PORT,PIN}. However, even that is a wart, as they should be
derived from the existing definition of MMCFS_SPI_NUM, instead of
defining the same thing in two ways.

If you let me know when you've reorganized I'll be happy to do testing
and add any remaining fixes

    M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

> Thanks.
>
> For what it's worth, current svn head (r863) seems to include the
> changes that break MMCFS on other platforms, leaving:
>
> // asserts the CS pin to the card
> static
> void SELECT (void)
> {
>  platform_pio_op( MMCFS_CS_PORT , ( ( u32 ) 1 << MMCFS_CS_PIN ),
> PLATFORM_IO_PIN_CLEAR );
>        //platform_spi_select( MMCFS_SPI_NUM, PLATFORM_SPI_SELECT_ON
> ); // select sd card pin
> }

Yes, I left that commented out as a reminder that I should probably do
something about it.

> now only the tiny attached patch is needed to make MMCFS work on
> Mizar32 and EVK1100 (and EVK1101 if we can test it), defining
> MMCFS_CS_{PORT,PIN}. However, even that is a wart, as they should be
> derived from the existing definition of MMCFS_SPI_NUM, instead of
> defining the same thing in two ways.

Yes and no. If the SPI SS pin can be set on and off using also the PIO
subsystem, not only the SPI subsystem (I didn't know this was possible
on the Atmels, although it makes all the sense in the world now that I
think about it :) ) then the user might want to use a different SS pin
for whatever reason.
I think I'd rather have your latest patch for now and deffer the MMCFS
platform interface support for some other time. It doesn't seem to
make much sense for now.

Best,
Bogdan

> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Hi,

On Fri, Dec 17, 2010 at 5:36 PM, Martin Guy <[hidden email]> wrote:
> now only the tiny attached patch is needed to make MMCFS work on
> Mizar32 and EVK1100 (and EVK1101 if we can test it), defining
> MMCFS_CS_{PORT,PIN}.

Your patch is now in trunk.

Thanks,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 18 December 2010 18:55, Bogdan Marinescu <[hidden email]> wrote:
> Hi,
>
> On Fri, Dec 17, 2010 at 5:36 PM, Martin Guy <[hidden email]> wrote:
>> now only the tiny attached patch is needed to make MMCFS work on
>> Mizar32 and EVK1100 (and EVK1101 if we can test it), defining
>> MMCFS_CS_{PORT,PIN}.
>
> Your patch is now in trunk.

Thanks. That works fine now.
It also works with the tiny patch that I forgot to attach, which is:

--- elua-svn.orig/src/elua_mmc.c 2011-01-15 15:41:26.274154000 +0100
+++ elua-svn/src/elua_mmc.c 2011-01-15 15:42:06.974154016 +0100
@@ -35,14 +35,14 @@
 static
 void SELECT (void)
 {
-    platform_pio_op( MMCFS_CS_PORT , ( ( u32 ) 1 << MMCFS_CS_PIN ),
PLATFORM_IO_PIN_CLEAR );
+    platform_spi_select( MMCFS_SPI_NUM, PLATFORM_SPI_SELECT_ON );
 }

 // de-asserts the CS pin to the card
 static
 void DESELECT (void)
 {
-    platform_pio_op( MMCFS_CS_PORT, ( ( u32 ) 1 << MMCFS_CS_PIN ),
PLATFORM_IO_PIN_SET );
+    platform_spi_select( MMCFS_SPI_NUM, PLATFORM_SPI_SELECT_OFF );
 }


Which seems more elegant, or is this the change that you say breaks
MMCFS on other platforms?
platform_spi_select() is present in the avr32, stm32 and lm3s ports.

    M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

> Which seems more elegant, or is this the change that you say breaks
> MMCFS on other platforms?

Yes, this was the change that broke MMCFS on other platforms.

> platform_spi_select() is present in the avr32, stm32 and lm3s ports.

Thanks, I'll take a better look at that function.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Sun, Jan 16, 2011 at 3:00 PM, Bogdan Marinescu
<[hidden email]> wrote:
>> Which seems more elegant, or is this the change that you say breaks
>> MMCFS on other platforms?
>
> Yes, this was the change that broke MMCFS on other platforms.
>
>> platform_spi_select() is present in the avr32, stm32 and lm3s ports.
>
> Thanks, I'll take a better look at that function.

I took a look. The function is indeed implemented in stm32 and lm3s
but it doesn't do anything in these backend, it's essentially a NOP. I
think I'll remove it from the platform interface. AVR32 can still use
it if needed (although at this point I'm not even sure it's really
needed) from a platform-specific module.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev