Shop OBEX P1 Docs P2 Docs Learn Events
Board configuration and cache driver for the new Propeller Platform USB Board — Parallax Forums

Board configuration and cache driver for the new Propeller Platform USB Board

David BetzDavid Betz Posts: 14,516
edited 2012-06-11 09:27 in Propeller 1
I've attached a board configuration file for Martin Hodge's new Propeller Platform USB board with the SPI flash footprint. This uses the generic SPI flash cache driver and is the first public use of the propeller-load feature of board subtypes. This configuration file will work with PP-USB boards with the SPI flash and SD card configured on P0-P4 or configured on P16-P20.

Warning: This is completely untested since I don't have one of these boards.

To use this board configuration file with the devices on P0-P4: 
propeller-load -b pp-usb-2
To use this board configuration file with the devices on P16-P20: 
propeller-load -b pp-usb-2:alternate
I'm not sure if the subtype can be specified in SimpleIDE. Maybe Steve will comment on that.
cfg
cfg
pp-usb-2.cfg
768B
dat
dat
spi_flash_cache.dat
1K
«1

Comments

  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-05-25 08:48
    Great, David. The version of PropGCC that comes with SIDE 0.6.12 seems to have that .dat driver already, so that's good. I'll give the board config a try.
  • mindrobotsmindrobots Posts: 6,506
    edited 2012-05-25 09:09
    Great work!

    Does this mean the PP-USB-2 is close to becoming a reality??? Soon, we'll be able to get our grubby little bits on it??
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-05-25 09:31
    David, I need a little more help...

    When I add that file to C:\propgcc\propeller-load\ the following options appear in SIDE's "Board Type" drop-down:

    pp-usb-2
    pp-usb-2:DEFAULT
    pp-usb-2:ALTERNATE
    pp-usb-2-SDLOAD
    pp-usb-2-SDXMMC

    I'm assuming that the "DEFAULT" one is the one I want.

    What I'm seeing in the cfg is
    [default]
# do=0 clk=1 di=2 sd-cs=3 fl-cs=4
    cache-param1: 0x02010021 # 0xooiiccpp - oo=mosi ii=miso cc=sck pp=cs-protocol
    cache-param2: 0x04000000 # 0xssxxxxxx - ss=cs
    sdspi-do: 0
    sdspi-clk: 1
    sdspi-di: 2
    sdspi-cs: 3

    Are the "cache-param" entries what controls comms to the flash chip? If so, shouldn't cache-param1 need to be 0x02000121 ? (the miso and sck parms seem to be swapped)

    Should I be using an SD card at the same time?

    Which memory model(s) should I test with?

    I'm trying to get the hello.c that opens up with SIDE to work.
  • David BetzDavid Betz Posts: 14,516
    edited 2012-05-25 09:34
    Martin Hodge wrote: »
    David, I need a little more help...

    When I add that file to C:\propgcc\propeller-load\ the following options appear in SIDE's "Board Type" drop-down:

    pp-usb-2
    pp-usb-2:DEFAULT
    pp-usb-2:ALTERNATE
    pp-usb-2-SDLOAD
    pp-usb-2-SDXMMC

    I'm assuming that the "DEFAULT" one is the one I want.

    What I'm seeing in the cfg is
    [default]
# do=0 clk=1 di=2 sd-cs=3 fl-cs=4
    cache-param1: 0x02010021 # 0xooiiccpp - oo=mosi ii=miso cc=sck pp=cs-protocol
    cache-param2: 0x04000000 # 0xssxxxxxx - ss=cs
    sdspi-do: 0
    sdspi-clk: 1
    sdspi-di: 2
    sdspi-cs: 3

    Are the "cache-param" entries what controls comms to the flash chip? If so, shouldn't cache-param1 need to be 0x02000121 ? (the miso and sck parms seem to be swapped)

    Should I be using an SD card at the same time?

    Which memory model(s) should I test with?

    I'm trying to get the hello.c that opens up with SIDE to work.
    Actually, either "pp-usb-2" or "pp-usb-2:DEFAULT" would work since if you leave off the subtype the loader assumes "default".
  • David BetzDavid Betz Posts: 14,516
    edited 2012-05-25 09:36
    Martin Hodge wrote: »
    David, I need a little more help...

    When I add that file to C:\propgcc\propeller-load\ the following options appear in SIDE's "Board Type" drop-down:

    pp-usb-2
    pp-usb-2:DEFAULT
    pp-usb-2:ALTERNATE
    pp-usb-2-SDLOAD
    pp-usb-2-SDXMMC

    I'm assuming that the "DEFAULT" one is the one I want.

    What I'm seeing in the cfg is
    [default]
# do=0 clk=1 di=2 sd-cs=3 fl-cs=4
    cache-param1: 0x02010021 # 0xooiiccpp - oo=mosi ii=miso cc=sck pp=cs-protocol
    cache-param2: 0x04000000 # 0xssxxxxxx - ss=cs
    sdspi-do: 0
    sdspi-clk: 1
    sdspi-di: 2
    sdspi-cs: 3

    Are the "cache-param" entries what controls comms to the flash chip? If so, shouldn't cache-param1 need to be 0x02000121 ? (the miso and sck parms seem to be swapped)

    Should I be using an SD card at the same time?

    Which memory model(s) should I test with?

    I'm trying to get the hello.c that opens up with SIDE to work.
    Sorry, I missed the second part of your question. What the loader calls "di" is actually "mosi" and what it calls "do" is actually "miso". In other words, the directions are from the viewpoint of the device. I used that terminology because the driver I based this on used that.
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-05-25 09:44
    You also missed the 3rd, 4th and 5th parts. ;)

    But with regard to the cache-param1. I understand the difference between the data in and out, but according to the comment on that line ii is set to pin 1, which is the CLK line, and cc is set to pin 0, which is the do. The problem (if I'm understanding it correctly) is miso and sck are swapped, not miso and mosi.
  • David BetzDavid Betz Posts: 14,516
    edited 2012-05-25 09:59
    Martin Hodge wrote: »
    You also missed the 3rd, 4th and 5th parts. ;)

    But with regard to the cache-param1. I understand the difference between the data in and out, but according to the comment on that line ii is set to pin 1, which is the CLK line, and cc is set to pin 0, which is the do. The problem (if I'm understanding it correctly) is miso and sck are swapped, not miso and mosi.

    I think you're right. The two are reversed. I told you it was untested! :-)
  • jazzedjazzed Posts: 11,803
    edited 2012-05-25 10:10
    I tried very hard to support this feature in SimpleIDE. I've never had an opportunity to test it though.
    Apparently the feature has been in the loader for some time, but I missed that somehow.

    SimpleIDE Version 0-6-11+ should work fine if I understood the feature definition correctly.

    --Steve
  • David BetzDavid Betz Posts: 14,516
    edited 2012-05-25 10:53
    Hi Martin,

    Have you had any luck getting PropGCC working with your new board? Need any help?

    Thanks,
    David
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-05-25 11:02
    David, no luck. I'm a complete Prop-GCC neophyte, so I have no idea what I'm even trying to test for. What memory model the flash is intended to be used with, etc. I may have to send a prototype to someone, who isn't a dolt, for some beta testing.

    At the hardware level, I'm not able to get any activity from any pin on my scope using the cache driver, regardless of what configuration I use.
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-05-25 11:32
    Got signs of life. It seems something doesn't like the [alternate] section. When I remove it I can get the hello.c to compile and produce output from the flash chip.

    In SIDE I used:

    Board Type: PPUSB-2
    Memory Model: XMMC

    Is this the correct testing method?
    cfg
    cfg
    ppusb-2.cfg
    514B
  • David BetzDavid Betz Posts: 14,516
    edited 2012-05-25 12:07
    Martin Hodge wrote: »
    Got signs of life. It seems something doesn't like the [alternate] section. When I remove it I can get the hello.c to compile and produce output from the flash chip.

    In SIDE I used:

    Board Type: PPUSB-2
    Memory Model: XMMC

    Is this the correct testing method?
    Yes, that should work. I'll look at the [alternate] tag handling to see if there might be a bug related to that in the loader. You're the first one to try it! :-)
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-05-25 17:51
    At some point I'd like to test a BIG program. Do you know of any candidates? Right now it looks, on my scope, as if there is a short burst of communication between Prop and flash after reset, then quiet as the program runs.

    Also, this chip is capable of quad SPI. Do these drivers handle that? It'd be nice to measure any speed difference too.
  • David BetzDavid Betz Posts: 14,516
    edited 2012-05-25 17:55
    Martin Hodge wrote: »
    At some point I'd like to test a BIG program. Do you know of any candidates? Right now it looks, on my scope, as if there is a short burst of communication between Prop and flash after reset, then quiet as the program runs.

    Also, this chip is capable of quad SPI. Do these drivers handle that? It'd be nice to measure any speed difference too.
    You can try demos/ebasic. It's pretty big. It certainly won't fit in the cache.

    There is an sqi_flash_cache.spin driver that should be able to run your chip in quadspi mode. You configure it in a similar manner to the way the single spi chip is configured. One restriction though is that the four data pins have to be adjacent.
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-05-25 21:58
    David Betz wrote: »
    the four data pins have to be adjacent.

    D'oh!
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-05-26 06:10
    when I try to compile xbasic.c I get reams of errors.
    Project Directory: C:/propgcc/demos/xbasic/
propeller-elf-gcc.exe -o a.out -Os -mxmmc -I . -fno-exceptions -Dprintf=__simple_printf xbasic.c
In file included from db_compiler.h:13:0,
                 from xbasic.c:2:
db_image.h:20:5: error: unknown type name 'int16_t'
db_image.h:21:5: error: unknown type name 'int16_t'
db_image.h:22:5: error: unknown type name 'uint16_t'
db_image.h:23:5: error: unknown type name 'int16_t'
db_image.h:24:5: error: unknown type name 'uint16_t'
db_image.h:25:5: error: unknown type name 'int16_t'
db_image.h:26:5: error: unknown type name 'uint16_t'
db_image.h:47:5: error: unknown type name 'int16_t'
db_image.h:52:5: error: unknown type name 'int16_t'
db_image.h:53:5: error: unknown type name 'int16_t'
In file included from xbasic.c:2:0:
db_compiler.h:114:5: error: unknown type name 'int16_t'
db_compiler.h:116:5: error: unknown type name 'uint8_t'
db_compiler.h:144:5: error: unknown type name 'int16_t'
db_compiler.h:145:5: error: unknown type name 'int16_t'
db_compiler.h:158:5: error: unknown type name 'uint8_t'
db_compiler.h:159:5: error: unknown type name 'uint8_t'
db_compiler.h:160:5: error: unknown type name 'uint8_t'
db_compiler.h:161:5: error: unknown type name 'uint8_t'
db_compiler.h:162:5: error: unknown type name 'uint8_t'
db_compiler.h:165:54: error: unknown type name 'int16_t'
db_compiler.h:174:5: error: unknown type name 'int16_t'
db_compiler.h:184:5: error: unknown type name 'int16_t'
db_compiler.h:188:5: error: unknown type name 'uint8_t'
db_compiler.h:189:5: error: unknown type name 'uint8_t'
db_compiler.h:190:5: error: unknown type name 'uint8_t'
db_compiler.h:192:5: error: unknown type name 'int16_t'
db_compiler.h:238:13: error: unknown type name 'int16_t'
db_compiler.h:274:15: error: unknown type name 'uint8_t'
db_compiler.h:276:1: error: unknown type name 'uint8_t'
db_compiler.h:279:36: error: unknown type name 'uint8_t'
db_compiler.h:285:1: error: unknown type name 'int16_t'
db_compiler.h:316:92: error: unknown type name 'int16_t'
db_compiler.h:338:1: error: unknown type name 'int16_t'
db_compiler.h:338:1: error: unknown type name 'uint8_t'
db_compiler.h:339:40: error: unknown type name 'int16_t'
db_compiler.h:339:56: error: unknown type name 'int16_t'
db_compiler.h:339:56: error: unknown type name 'uint8_t'
db_compiler.h:340:1: error: unknown type name 'int16_t'
db_compiler.h:340:1: error: unknown type name 'int16_t'
db_compiler.h:341:1: error: unknown type name 'int16_t'
In file included from xbasic.c:3:0:
db_vm.h:25:5: error: unknown type name 'int16_t'
db_vm.h:26:5: error: unknown type name 'int16_t'
db_vm.h:27:5: error: unknown type name 'int16_t'
db_vm.h:28:5: error: unknown type name 'int16_t'
db_vm.h:29:5: error: unknown type name 'uint8_t'
db_vm.h:56:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:57:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:58:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:59:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:60:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:61:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:62:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:63:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:64:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:65:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:66:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:67:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:68:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:69:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:70:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:71:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:72:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:73:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:74:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:75:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:76:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:77:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:78:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:79:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:80:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:81:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:82:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char'
db_vm.h:85:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Intrinsics'
db_vm.h:89:1: error: unknown type name 'uint8_t'
db_vm.h:95:21: error: unknown type name 'uint16_t'
db_vm.h:95:21: error: unknown type name 'uint8_t'
db_vm.h:96:23: error: unknown type name 'uint16_t'
db_vm.h:96:23: error: unknown type name 'uint8_t'
db_vm.h:96:23: error: unknown type name 'uint8_t'
xbasic.c:9:1: error: unknown type name 'uint8_t'
xbasic.c: In function 'main':
xbasic.c:23:5: error: unknown type name 'uint8_t'
Done. Build Failed!
Click error messages above to debug.
Check source for bad function call or global variable name.
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-05-26 06:33
    The ebasic makefile defines PROPELLER_GCC, USE_FDS and LOAD_SAVE. You should add these defines.
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-05-26 06:40
    I was going to try to buid ebasic with the Simple IDE, but it seems to have replaced the original ebasic.c with a small boiler-plate version. The orignal ebasic.c is lost. Is this a "feature" or a bug?

    Shouldn't SIDE retain the original source file with the same name as the project if it already exists?

    EDIT: OK, I found the problem. I created the project in a different path than demos/ebasic. I then tried to create a project in the correct directory, but it appears that SIDE will only create projects in new directories, so I just copied the ebasic.side file from the other path to resolve this.

    It would be nice if SIDE could create a project in an existing directory and use the existing source file with the same name as the project if it exists.
  • jazzedjazzed Posts: 11,803
    edited 2012-05-26 07:39
    Dave Hein wrote: »
    I was going to try to buid ebasic with the Simple IDE, but it seems to have replaced the original ebasic.c with a small boiler-plate version. The orignal ebasic.c is lost. Is this a "feature" or a bug?

    Shouldn't SIDE retain the original source file with the same name as the project if it already exists?

    EDIT: OK, I found the problem. I created the project in a different path than demos/ebasic. I then tried to create a project in the correct directory, but it appears that SIDE will only create projects in new directories, so I just copied the ebasic.side file from the other path to resolve this.

    It would be nice if SIDE could create a project in an existing directory and use the existing source file with the same name as the project if it exists.

    Hi Dave.

    I'll look into not letting an original file be over-written.

    A solution for using an existing main file is available.

    The "Set Project to Current File" button looks like a COG. It can be used with an existing main file.
    1. Open the existing file and click the Set Project button.
    2. Once the project is set, add files and -D like found in the ebasic Makefile.
    I've attached an original ebasic that I know works for testing.
    You'll have to choose your own board type of course.

    The ebasic2 in the repository doesn't like line numbers and I don't get it, so I'm avoiding it for now.

    addit:

    I've added David's syntax manual for ebasic. This particular version does not support NEW, LOAD, and SAVE, but everything else should work.

    Here is some basic code that I've been using for a while to see if performance is reasonable. The fastest XMMC solutions run it very quickly.
    list
OK
# add a comment
0 rem nothing in buffer
list
0 rem nothing in buffer
OK
# remove a comment
list
OK
# add the count program
10 print "Count to 100"
20 for n = 0 to 100
30  if n mod 10 = 0 then
40   print
50  end if
60  print n; " ";
70 next n
list
10 print "Count to 100"
20 for n = 0 to 100
30  if n mod 10 = 0 then
40   print
50  end if
60  print n; " ";
70 next n
OK
run
H:0 O:3 D:180 V:1 T:196
Count to 100


0 1 2 3 4 5 6 7 8 9 
10 11 12 13 14 15 16 17 18 19 
20 21 22 23 24 25 26 27 28 29 
30 31 32 33 34 35 36 37 38 39 
40 41 42 43 44 45 46 47 48 49 
50 51 52 53 54 55 56 57 58 59 
60 61 62 63 64 65 66 67 68 69 
70 71 72 73 74 75 76 77 78 79 
80 81 82 83 84 85 86 87 88 89 
90 91 92 93 94 95 96 97 98 99 
100 OK
    zip
    zip
    ebasic.zip
    38K
    txt
    txt
    README.txt
    1K
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-05-26 19:21
    That did the trick.
  • David BetzDavid Betz Posts: 14,516
    edited 2012-05-26 20:52
    In case you're interested, here is what the new board configuration file for the new Propeller Platform USB board looks like. This requires the changes I've just pushed to Google Code for propeller-load. The idea is to put as much as possible in the common section so that the subtypes are relatively simple. The funny curly braces around things like sdspi-di are to allow configuration variables to be used in C-like expressions. Without them, the embedded "-" in the configuration variable name would be parsed as a subtraction operator. 
    # [pp-usb-2]
# IDE:SDLOAD
# IDE:SDXMMC
clkfreq: 80000000
clkmode: XTAL1+PLL16X
baudrate: 115200
rxpin: 31
txpin: 30
sd-driver: sd_driver.dat
sdspi-do: {spi-base} + 0
sdspi-clk: {spi-base} + 1
sdspi-di: {spi-base} + 2
sdspi-cs: {spi-base} + 3
cachespi-cs: {spi-base} + 4
cache-driver: spi_flash_cache.dat
cache-size: 8K
cache-param1: ({sdspi-di} << 24) | ({sdspi-do} << 16) | ({sdspi-clk} << 8) | 0x21
cache-param2: {cachespi-cs} << 24

# P0 | P16 = DO
# P1 | P17 = CLK
# P2 | P18 = DI
# P3 | P19 = SD-CS
# P4 | P20 = FL-CS

[default]
    spi-base: 0

[alternate]
    spi-base: 16
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-05-28 20:15
    Thanks for the work, David. It looks very promising. I'm not able to get the source to compile right now. A temporary problem, I'm sure. But I've verified that the hardware works and that is what is most important right now for this project.
  • David BetzDavid Betz Posts: 14,516
    edited 2012-05-29 04:59
    Martin Hodge wrote: »
    Thanks for the work, David. It looks very promising. I'm not able to get the source to compile right now. A temporary problem, I'm sure. But I've verified that the hardware works and that is what is most important right now for this project.
    Which source are you having trouble compiling? The loader sources? If so, what kind of problem are you having?
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-05-30 09:16
    The build process errors out here: 
    gcc -Wall -I../loader/src -DLINUX -o gdbstub gdbstub.o config.o system.o port.o PLoadLib.o  osint_linux.o kernel_image.o 
config.o: In function `DumpFields':
config.c:(.text+0x65c): undefined reference to `TryParseNumericExpr'
config.o: In function `GetNumericConfigField':
config.c:(.text+0x9ba): undefined reference to `ParseNumericExpr'
collect2: ld returned 1 exit status
make: *** [gdbstub] Error 1
rm kernel_image.binary kernel_image.c
gdbstub make failed
  • jazzedjazzed Posts: 11,803
    edited 2012-05-30 10:02
    Hi Martin.

    This is caused by gdbstub not having expr.o in it's object list. We are having some other issues with the build right now.

    You can sit tight until we resolve the issues, or stay on revision 1395 with the gdbstub build step removed.

    Thanks,
    --Steve

    Martin Hodge wrote: »
    The build process errors out here: 
    gcc -Wall -I../loader/src -DLINUX -o gdbstub gdbstub.o config.o system.o port.o PLoadLib.o  osint_linux.o kernel_image.o 
config.o: In function `DumpFields':
config.c:(.text+0x65c): undefined reference to `TryParseNumericExpr'
config.o: In function `GetNumericConfigField':
config.c:(.text+0x9ba): undefined reference to `ParseNumericExpr'
collect2: ld returned 1 exit status
make: *** [gdbstub] Error 1
rm kernel_image.binary kernel_image.c
gdbstub make failed
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-05-30 12:13
    Thanks, Steve. NBD, I'll just wait a few days.
  • David BetzDavid Betz Posts: 14,516
    edited 2012-05-30 14:26
    Martin Hodge wrote: »
    The build process errors out here: 
    gcc -Wall -I../loader/src -DLINUX -o gdbstub gdbstub.o config.o system.o port.o PLoadLib.o  osint_linux.o kernel_image.o 
config.o: In function `DumpFields':
config.c:(.text+0x65c): undefined reference to `TryParseNumericExpr'
config.o: In function `GetNumericConfigField':
config.c:(.text+0x9ba): undefined reference to `ParseNumericExpr'
collect2: ld returned 1 exit status
make: *** [gdbstub] Error 1
rm kernel_image.binary kernel_image.c
gdbstub make failed
    This bug should be fixed now. I also pushed a change to propeller-load to get around a problem with it crashing when trying to write a spin binary file.
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-06-07 11:19
    David. Finally got around to testing your latest config scheme and it works both with and without ":alternate". Good job!
  • David BetzDavid Betz Posts: 14,516
    edited 2012-06-07 12:06
    Martin Hodge wrote: »
    David. Finally got around to testing your latest config scheme and it works both with and without ":alternate". Good job!
    Thanks for testing it and I'm glad it works. Your board looks really nice!
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2012-06-08 22:40
    What do I need to do to try the flash in qSPI mode? I have the chip connected to:

    IO0 - IO3 = 22 - 25
    SCK = 26
    /CS = 27
Sign In or Register to comment.