Another new XMMC hardware

Ariba · 2012-05-04 18:31

I try to adapt my board to PropGCC and Simple IDE. I've made some nice progress so far, but have also found some issues.
My Board has shared SD-card and SPI-Flash on the same SPI buss with separate CS pins.

As a first step I have modified a CNF file with the spi_flache_cache.dat as driver, set the right pins there for Flash SPI and SD card. To my surprise the XMMC load and execution from Flash and from SD card worked immediatly

The problem I have is with the file_test example, when I execute the code from Flash and try to access the SD card. I always get an "I/O Error" on SD access in this configuration.
If I execute from SD card, I can access the SD card with no problems, so I guess it's a hardware problem because of the shared SPI buss. I thought this sharing works for the C3 drivers. So is there a trick (locks or so) that needs to be implemented in the spi_flash_cache driver?

Andy

David Betz · 2012-05-04 19:16

Ariba wrote: »

I try to adapt my board to PropGCC and Simple IDE. I've made some nice progress so far, but have also found some issues.
My Board has shared SD-card and SPI-Flash on the same SPI buss with separate CS pins.

As a first step I have modified a CNF file with the spi_flache_cache.dat as driver, set the right pins there for Flash SPI and SD card. To my surprise the XMMC load and execution from Flash and from SD card worked immediatly

The problem I have is with the file_test example, when I execute the code from Flash and try to access the SD card. I always get an "I/O Error" on SD access in this configuration.
If I execute from SD card, I can access the SD card with no problems, so I guess it's a hardware problem because of the shared SPI buss. I thought this sharing works for the C3 drivers. So is there a trick (locks or so) that needs to be implemented in the spi_flash_cache driver?

Andy

Hi Andy,

I'm glad to hear you were successful in getting the spi_flash_cache.spin driver to work with your board. Congratulations! You are correct that we have cache and SD card access working on the C3 with shared pins. I'm not sure why it isn't working on your board. I looked at the spi_flash_cache.spin code and it looks like it lets go of the SPI pins when it is idle and I'm pretty sure that the SD card access code uses a small function in hub memory to access its SD card driver so this should work. Ted (denominator) did most of the recent work with the SD card drivers. Maybe he'll see this message and offer some advice.

David

Ariba · 2012-05-04 21:01

Thanks David

I have tried several modifications of the spi_flash_cache driver, also deselect all pins expicitly with MOV DIRA,#0 (I have a pullup at the Flash CS pin), but no success. So I think it is the SD driver that does something wrong.

Here is my CNF file:

# [PropinoPP]
# IDE:SDXMMC
    clkfreq: 80000000
    clkmode: XTAL1+PLL16X
    baudrate: 115200
    rxpin: 31
    txpin: 30
    tvpin: 12   # only used if TV_DEBUG is defined
    cache-driver: spi_flash_cache.dat
    cache-size: 8K
    cache-param1: 0x16141501 # 0xooiiccpp - oo=mosi=22 ii=miso=20 cc=sck=21 pp=cs-protocol
    cache-param2: 0x1C000000 # 0xaa000000 - aa=cs-pin=28 (if pp=01)
    sd-driver: sd_driver.dat
    sdspi-do: 20
    sdspi-clk: 21
    sdspi-di: 22
    sdspi-cs: 23

I'm not sure if I have to set also the sd-clr, sd-inc and sd-addr pins to something (but then to what?).

Andy

David Betz · 2012-05-05 04:11

Ariba wrote: »
Thanks David

I have tried several modifications of the spi_flash_cache driver, also deselect all pins expicitly with MOV DIRA,#0 (I have a pullup at the Flash CS pin), but no success. So I think it is the SD driver that does something wrong.

Here is my CNF file:
# [PropinoPP]
# IDE:SDXMMC
    clkfreq: 80000000
    clkmode: XTAL1+PLL16X
    baudrate: 115200
    rxpin: 31
    txpin: 30
    tvpin: 12   # only used if TV_DEBUG is defined
    cache-driver: spi_flash_cache.dat
    cache-size: 8K
    cache-param1: 0x16141501 # 0xooiiccpp - oo=mosi=22 ii=miso=20 cc=sck=21 pp=cs-protocol
    cache-param2: 0x1C000000 # 0xaa000000 - aa=cs-pin=28 (if pp=01)
    sd-driver: sd_driver.dat
    sdspi-do: 20
    sdspi-clk: 21
    sdspi-di: 22
    sdspi-cs: 23
I'm not sure if I have to set also the sd-clr, sd-inc and sd-addr pins to something (but then to what?).

Andy

I think there is already a MOV DIRA,#0 in the spi_flash_cache driver just before it enters it's command wait loop so it should be clear of all pins when it is not in operation. You have to be careful that you don't generate a reference to external memory that is outside of the current cache line if you're going to use those pins for other purposes though. That is why I said that the SD code uses a mailbox command handler that is in hub memory{

static uint32_t __attribute__((section(".hubtext"))) do_cmd(uint32_t cmd)
{
    sd_mbox[0] = cmd;
    while (sd_mbox[0]);
    return sd_mbox[1];
}

jazzed · 2012-05-05 09:27

Andy,

Assuming you have #include <propeller.h>

static uint32_t __attribute__((section(".hubtext"))) do_cmd(uint32_t cmd) ....

can be replaced with

static uint32_t HUBTEXT do_cmd(uint32_t cmd) ....

You shouldn't need to set the CLR, MASK, or ADDR bits in the driver pins unless you use the C3 MUX or a SPI selector.

Did you change the "mount(...)" function in filetest? It's set by default to use C3 because of #define C3_CARD in the code - which needs to be removed for other _SD_Params definitions. I assume you've done all this though.

@denominator (Ted) has an example of using locks .... He wrote a very detailed description of his SPI and other sharing solution with locks and source code examples here: http://code.google.com/p/propgcc/issues/detail?id=44 I'm always impressed with his work.

Thanks,
--Steve

Ariba · 2012-05-05 11:58

Thank you Steve and David

I have not set the SD_Pins before mount, I thought the driver uses the config file for that. If I run from SD-XMMC the filetest.c works, so it seems to know the SD pins. I think the SD driver also need to know the CS logic.

Now I have tried to set the right Pins, but I get the same result: "./: I/O Error".

Interessting that in the link about locking, the spi_flash_cache driver is not in the list of modified drivers. The tests are all for a C3 platform which I not have. So If I have time today I modify the C3_cache.spin driver for my Flash connection, and try it with that driver.

Another test I will do is to connect the Flash on other pins than the SD card to check if it is really the SPI sharing that generates the problem.

Thanks again
I'm really impressed how easy it is to work with the SimpleIDE and to adapt a XMM board to it and to PropGCC. As long as you use the SD-XMMC solution all works also yet, but Flash-XMMC is up to 5 times faster on some of my tests.

Andy

David Betz · 2012-05-05 13:14

Ariba wrote: »

Thank you Steve and David

I have not set the SD_Pins before mount, I thought the driver uses the config file for that. If I run from SD-XMMC the filetest.c works, so it seems to know the SD pins. I think the SD driver also need to know the CS logic.

Now I have tried to set the right Pins, but I get the same result: "./: I/O Error".

Interessting that in the link about locking, the spi_flash_cache driver is not in the list of modified drivers. The tests are all for a C3 platform which I not have. So If I have time today I modify the C3_cache.spin driver for my Flash connection, and try it with that driver.

Another test I will do is to connect the Flash on other pins than the SD card to check if it is really the SPI sharing that generates the problem.

Thanks again
I'm really impressed how easy it is to work with the SimpleIDE and to adapt a XMM board to it and to PropGCC. As long as you use the SD-XMMC solution all works also yet, but Flash-XMMC is up to 5 times faster on some of my tests.

Andy

The SD cache driver uses the config file settings for the sd pins. The normal sd driver does not. We need to change that. There is a way to handle that now with variables that get patched by the loader but it isn't implemented for the filesystem code yet.

Ariba · 2012-05-05 20:11

Turned out that I used an outdated filetest.c code from the Demo package: propgcc-demos_2012-03-07.zip.
This code had not the different settings per defines of the new version.
With the new version I was able to set the right pins for my Board, and it works now with separate or shared pins

Is there a description of the "AttachmentType:" options?
I have it now set to "AttachmentType: _SDA_SingleSPI" also with a shared SPI bus, and it seems to work.
Or do I need to set it to: "AttachmentType: _SDA_ParallelDeMUX" and set the right pin masks to select my SD-CS pin? This should be possible also if I have no demultiplexer in my hardware (just 2 separate CS pins for Flash and SD card).

Andy

jazzed · 2012-05-05 21:14

Ariba wrote: »

With the new version I was able to set the right pins for my Board, and it works now with separate or shared pins

Excellent.

Guess a new demo package download is needed.

I'm sorry our documentation is lacking right now. We have started marking up headers with Doxygen for standard libraries and any other libraries that are part of the distribution. We will be producing pdf and html documentation from the markup.

Hoping Dave Hein or someone else can explain the AttachmentType. It's a little mysterious to me too. I think _SDA_SingleSPI is for normal 4 pin SPI interfaces. Not sure about the rest.

Thanks,
--Steve

David Betz · 2012-05-06 03:10

jazzed wrote: »

Excellent.

Guess a new demo package download is needed.

I'm sorry our documentation is lacking right now. We have started marking up headers with Doxygen for standard libraries and any other libraries that are part of the distribution. We will be producing pdf and html documentation from the markup.

Hoping Dave Hein or someone else can explain the AttachmentType. It's a little mysterious to me too. I think _SDA_SingleSPI is for normal 4 pin SPI interfaces. Not sure about the rest.

Thanks,
--Steve

I'm pretty sure that "serial mux" is what the spi_flash_cache.spin driver calls "C3-mode" with a counter and clear and that "parallel mux" is something like a 3-8 decoder with an optional CS pin. This is the scheme that I understand is used by Bill Henning's PropCade and maybe Morpheus as well. I'd like to convert everything over to the two long configuration scheme that spi_flash_cache.spin to make it easier for the loader to patch in the correct values from the config file but that change is still under discussion.

Dave Hein · 2012-05-06 05:57

I think Denominator made the changes for the more flexible CS logic. David's explanation sounds correct to me.

David Betz · 2012-05-06 06:16

Dave Hein wrote: »

I think Denominator made the changes for the more flexible CS logic. David's explanation sounds correct to me.

I'm afraid I'm responsible for the funky way that CS is handled in the SD driver. I did it originally for the SD cache driver but Dave adopted it for the filesystem support as well.

Dave Hein · 2012-05-06 06:30

I modified the FSRW SPI driver to support the C3 board's CS method, but Ted (Denominator) made the most-recent file driver changes.

David Betz · 2012-05-06 06:33

Dave Hein wrote: »

I modified the FSRW SPI driver to support the C3 board's CS method, but Ted (Denominator) made the most-recent file driver changes.

Oops, I meant Ted not Dave. Sorry. Also, fsrw is used by the sd cache loader but isn't actually used during runtime. The propgcc library code is based on dosfs.c and uses an sd driver written using gas.

Ariba · 2012-05-06 09:49

David Betz wrote: »

I'm pretty sure that "serial mux" is what the spi_flash_cache.spin driver calls "C3-mode" with a counter and clear and that "parallel mux" is something like a 3-8 decoder with an optional CS pin. This is the scheme that I understand is used by Bill Henning's PropCade and maybe Morpheus as well. I'd like to convert everything over to the two long configuration scheme that spi_flash_cache.spin to make it easier for the loader to patch in the correct values from the config file but that change is still under discussion.

Yes this is also how I understand it.
What is unclear to me:

1) If you don't use "serial_mux" or "parallel_mux" but "singleSPI" can the SPI bus still be muxed with single CS pins for a Flash and a SDcard device, or does the driver expect that the SDcard is the only (the single) device at this SPI connection.

2) In "parallel mux" mode with a decoder chip, you can only specify the pin mask for the decoder select pins and the active state of these pins to select the device. But what is the idle state (to deselect all devices) ? I hope it is all ONEs, then you can use this mode also for a single, active Low CS pin. (only necessary if 1) not handels multiplexed devices).

I have tried both variants and both settings seem to work.

Andy

David Betz · 2012-05-06 13:05

Ariba wrote: »

1) If you don't use "serial_mux" or "parallel_mux" but "singleSPI" can the SPI bus still be muxed with single CS pins for a Flash and a SDcard device, or does the driver expect that the SDcard is the only (the single) device at this SPI connection.

Yes, you could share the MISO, CLK, and MOSI pins with other devices as long as each has it's own CS pin.

2) In "parallel mux" mode with a decoder chip, you can only specify the pin mask for the decoder select pins and the active state of these pins to select the device. But what is the idle state (to deselect all devices) ? I hope it is all ONEs, then you can use this mode also for a single, active Low CS pin. (only necessary if 1) not handels multiplexed devices).

The idle state is all zeros as it stands now but this mode has never been tested since I don't have any boards that use it. It was added to support boards fro Bill Henning so maybe he'll say whether his boards use all zeros or all ones for the idle state. If necessary, we could support either by providing an "idle value" setting as well as a "selected value" setting.

Ariba · 2012-05-07 19:57

Hi David

OK I use now the SingleSPI mode, and had no problems so far.

If I think a bit more about the idle state in "Paralllel Mux" I would say the state is anyway "floating pins" now, because the drivers gives all the pins free with "MOV DIRA,#0". So the hardware needs pullups / pulldowns for a safe idle state. Because all cogs OR the pins, the other possibility would be to set all MUX pins to zero, so another driver (cog) can overwrite them with Highs.

Andy

pedward · 2012-05-07 21:31

Maybe a dumb question, but where's the source code for all of these drivers? Steve mentioned needing some help and I've designed a daughter board for the PropKEY to provide flash/RAM.

jazzed · 2012-05-07 22:10

pedward wrote: »

Maybe a dumb question, but where's the source code for all of these drivers? Steve mentioned needing some help and I've designed a daughter board for the PropKEY to provide flash/RAM.

Not a dumb question. This is one area where we haven't been very explicit.

All the cache drivers are written in PASM and live here:
http://code.google.com/p/propgcc/source/browse/#hg%2Floader%2Fspin
I've been itching to write one in COGC

You can look at raw versions of these files to copy without using source control to pull a repository.

Procedure:

1. Write a cache driver.

2. Build a cache driver for the .cfg file.

All you have to do to build a *cache.dat is use BSTC.
Roy's Spin compiler also has the -c feature.

For example:
bstc -Ograux -c ssf_cache.spin
This makes a file called ssf_cache.dat

3. Copy the resulting .dat file to the propeller-load folder.

4. Finally add your cache.dat to the .cfg file.

Follow the the example below.

[FONT=courier new]# [ssf][/FONT]
[FONT=courier new]    clkfreq: 80000000[/FONT]
[FONT=courier new]    clkmode: XTAL1+PLL16X[/FONT]
[FONT=courier new]    baudrate: 115200[/FONT]
[FONT=courier new]    rxpin: 31[/FONT]
[FONT=courier new]    txpin: 30[/FONT]
[FONT=courier new]    tvpin: 12   # only used if TV_DEBUG is defined[/FONT]
[FONT=courier new]    cache-driver: ssf_cache.dat[/FONT]
[FONT=courier new]    cache-size: 8K[/FONT]
[FONT=courier new]    cache-param1: 0[/FONT]
[FONT=courier new]    cache-param2: 0
[/FONT]

The cache-driver tag is for specifying your cache_driver.dat
Cache parameters, cache-param1 and cache-param2 are for cache specific initialization.
David added a single SQI driver that has pin parameters for example.

Step 1 can be the most challenging.

I've mostly copied the cache algorithm from one of the other cache drivers
and plugged in my own routines for BREAD and BWRITE.

There is a test program here for testing sram and sdram cache drivers.
http://code.google.com/p/propgcc/source/browse/loader/spin/test_cache.spin

I've used this to bring up EEPROM and Flash cache drivers too.
It is currently set to work with eeprom_cache.spin.

I have some SRAM code for you, but it is not using the current cache algorithm.

Thanks,
--Steve

Ariba · 2012-05-07 23:07

As long as you have only a single flash chip, the "spi_flash_cache.dat" driver should do the job. It is well configurable from the .CFG file.

But I have my flash chip connected a bit different, with connected DI and DO pins, and this is not supported by the spi_flash_cache driver. So I have made a modified driver called 3p_flash_cache (3p for 3-pin SPI):

Andy

David Betz · 2012-05-08 04:20

Ariba wrote: »

As long as you have only a single flash chip, the "spi_flash_cache.dat" driver should do the job. It is well configurable from the .CFG file.

But I have my flash chip connected a bit different, with connected DI and DO pins, and this is not supported by the spi_flash_cache driver. So I have made a modified driver called 3p_flash_cache (3p for 3-pin SPI):

Andy

Just out of curiosity, why did you wire your flash chip this way? Why not just parallel the SD DI/CLK/DO pins? What advantage is gained by connecting DI and DO?

pedward · 2012-05-08 15:58

To reduce I/O. I did the same on the 8 way RAM. I chips wired in parallel, uses 8 I/O instead of 16.

David Betz · 2012-05-08 16:59

pedward wrote: »

To reduce I/O. I did the same on the 8 way RAM. I chips wired in parallel, uses 8 I/O instead of 16.

That's sort of what I figured but in this case you're piggybacking on the SD SPI pins so you have all three available so I wondered why you didn't use both data pins.

Ariba · 2012-05-08 17:23

David Betz wrote: »

Just out of curiosity, why did you wire your flash chip this way? Why not just parallel the SD DI/CLK/DO pins? What advantage is gained by connecting DI and DO?

Yes this spares one Prop I/O pin. It's possible to add another chip (an SPI RAM) on the free MISO line with the same Chip select.

But the main reason is, that some SD drivers do not release the DO pin of the SD card, so the SD card outputs always a High on this line. I know the PropGCC SD driver does it correct, but I hope my board will work with existing, unmodified drivers in Spin and other Languages this way.

Andy

David Betz · 2012-05-08 20:06

Ariba wrote: »

Yes this spares one Prop I/O pin. It's possible to add another chip (an SPI RAM) on the free MISO line with the same Chip select.

But the main reason is, that some SD drivers do not release the DO pin of the SD card, so the SD card outputs always a High on this line. I know the PropGCC SD driver does it correct, but I hope my board will work with existing, unmodified drivers in Spin and other Languages this way.

Andy

Okay, I understand. Thanks for the explanation!

Another new XMMC hardware

Comments