Shop OBEX P1 Docs P2 Docs Learn Events
problem __enable_spi_locking_ret not being defined from xmm model — Parallax Forums

problem __enable_spi_locking_ret not being defined from xmm model

Mike PetryMike Petry Posts: 14
edited 2014-01-24 06:40 in Propeller 1
I posted an issue over at code.google.com of not being able to link programs that do file_io via stdio.

I tried compiling the example at :

https://sites.google.com/site/propellergcc/documentation/libraries#TOC-Stdio-Devices-Library
It appears to be a few missing definitions resulting from the new code for spi_locking that was added in early January.

This should only impact folks that are doing file based stdio using recent bits from the tree (since January 1).
I'm using the src tree, because propeller-load that comes with SimpleIDE 9.9.45 was crashing.
propeller-load in the src tree provides the expected behavior.

Host system is a Mac running 10.9.1 Mavericks with the latest Xcode.

-Mike

Comments

  • David BetzDavid Betz Posts: 14,516
    edited 2014-01-23 12:39
    Mike Petry wrote: »
    I posted an issue over at code.google.com of not being able to link programs that do file_io via stdio.

    I tried compiling the example at :

    https://sites.google.com/site/propellergcc/documentation/libraries#TOC-Stdio-Devices-Library
    It appears to be a few missing definitions resulting from the new code for spi_locking that was added in early January.

    This should only impact folks that are doing file based stdio using recent bits from the tree (since January 1).
    I'm using the src tree, because propeller-load that comes with SimpleIDE 9.9.45 was crashing.
    propeller-load in the src tree provides the expected behavior.

    Host system is a Mac running 10.9.1 Mavericks with the latest Xcode.

    -Mike
    Sorry, I forgot to make _enable_spi_locking_ret a global. I'll fix that now.

    Edit: I just pushed that change. You shouldn't get that error if you pull updates from Google Code and rebuild. Sorry about that!
  • David BetzDavid Betz Posts: 14,516
    edited 2014-01-23 13:14
    By the way, you said that the version of propeller-load that came with SimpleIDE crashed. Any chance you could post the .elf file that cause the crash?

    Thanks!
    David
  • Mike PetryMike Petry Posts: 14
    edited 2014-01-23 19:00
    David Betz wrote: »
    By the way, you said that the version of propeller-load that came with SimpleIDE crashed. Any chance you could post the .elf file that cause the crash?

    Thanks!
    David

    Sorry for the delay. I needed to setup a machine with a fresh install of SimpleIDE and one with a fresh compile of the tree .
    I used a C3 as the target for simple testing. but the target hardware is different. I've added a .bin extension to the name in order to
    upload it for attachment. The binary is in a Dropbox folder shared by the two macs both running Mavericks 10.9.1.
    I moved the C3 between them and ran the two different propeller-loads below:

    Using the old bins from SimpleIDE 0.0.45

    host52:consoleio_xmmc petry [master] $ propeller-load -z -b c3 consoleio -r -t
    Propeller Version 1 on /dev/cu.usbserial-00001004
    Patching __cfg_sdspi_config1 with 090a0b13
    Patching __cfg_sdspi_config2 with 19080005
    Abort trap: 6
    host52:consoleio_xmmc petry [master] $

    From a fresh build of the tree


    dolly:consoleio_xmmc petry [master] $ propeller-load -b c3 -z consoleio -e -r -t -p /dev/cu.usbserial-0000101D
    Propeller Version 1 on /dev/cu.usbserial-0000101D
    Patching __cfg_sdspi_config1 with 090a0b13
    Patching __cfg_sdspi_config2 with 19080005
    Loading the serial helper to hub memory
    10392 bytes sent
    Verifying RAM ... OK
    Loading 'consoleio.pex' to SD card
    38560 bytes sent
    error: load failed
    dolly:consoleio_xmmc petry [master] $

    I'll investigate the load failure in the morning, but am glad to have gotten past the abort Trap: 6 and the
    undefined symbols. :-)

    BTW: Don't the other crt0s need to have the symbols defined? I tried compiling with the LMM
    and had both __enable_spi_locking_ret and __enable_spi_locking undefined.



  • David BetzDavid Betz Posts: 14,516
    edited 2014-01-24 04:00
    Mike Petry wrote: »
    Sorry for the delay. I needed to setup a machine with a fresh install of SimpleIDE and one with a fresh compile of the tree .
    I used a C3 as the target for simple testing. but the target hardware is different. I've added a .bin extension to the name in order to
    upload it for attachment. The binary is in a Dropbox folder shared by the two macs both running Mavericks 10.9.1.
    I moved the C3 between them and ran the two different propeller-loads below:

    Using the old bins from SimpleIDE 0.0.45

    host52:consoleio_xmmc petry [master] $ propeller-load -z -b c3 consoleio -r -t
    Propeller Version 1 on /dev/cu.usbserial-00001004
    Patching __cfg_sdspi_config1 with 090a0b13
    Patching __cfg_sdspi_config2 with 19080005
    Abort trap: 6
    host52:consoleio_xmmc petry [master] $

    From a fresh build of the tree


    dolly:consoleio_xmmc petry [master] $ propeller-load -b c3 -z consoleio -e -r -t -p /dev/cu.usbserial-0000101D
    Propeller Version 1 on /dev/cu.usbserial-0000101D
    Patching __cfg_sdspi_config1 with 090a0b13
    Patching __cfg_sdspi_config2 with 19080005
    Loading the serial helper to hub memory
    10392 bytes sent
    Verifying RAM ... OK
    Loading 'consoleio.pex' to SD card
    38560 bytes sent
    error: load failed
    dolly:consoleio_xmmc petry [master]

    I'll investigate the load failure in the morning, but am glad to have gotten past the abort Trap: 6 and the
    undefined symbols. :-)
    You're passing -z to propeller-load which means you're trying to use the SD cache driver. That is not supported in the default branch because the mechanism for handling external memory has changed and the SD cache driver has not yet been ported to the new scheme. Since you're using a C3, why not use the C3 cache driver which will utilize the C3's onboard SPI flash and SRAM chips? They will perform much better than the SD cache.
    BTW: Don't the other crt0s need to have the symbols defined? I tried compiling with the LMM
    and had both __enable_spi_locking_ret and __enable_spi_locking undefined.
    Yes and no. It looks like I forgot to put ifdefs around the call to _enable_spi_locking in the CMM and LMM library builds. Since they don't use cache drivers they have no need for SPI locking. Thanks for mentioning that.
  • Mike PetryMike Petry Posts: 14
    edited 2014-01-24 05:27
    David Betz wrote: »
    You're passing -z to propeller-load which means you're trying to use the SD cache driver. That is not supported in the default branch because the mechanism for handling external memory has changed and the SD cache driver has not yet been ported to the new scheme. Since you're using a C3, why not use the C3 cache driver which will utilize the C3's onboard SPI flash and SRAM chips? They will perform much better than the SD cache.


    Yes and no. It looks like I forgot to put ifdefs around the call to _enable_spi_locking in the CMM and LMM library builds. Since they don't use cache drivers they have no need for SPI locking. Thanks for mentioning that.

    Thanks for the fixes, I look forward to the ifdefs for the other model library builds.

    My target hardware isn't a C3, I just use one for testing. It only has eeprom and SPI available for cache. My old code took advantage of the old SD cache driver. The performance wasn't stellar, but acceptable.
    I'm trimming some code and hope to fit all the needed functionality in to the LMM model (That's how I stumbled across the undefines). If it won't fit, I have a few SPI memory chips that I'll try adding to the hardware for cache and move back to the xmm model.

    Thanks Again,
    Mike
  • David BetzDavid Betz Posts: 14,516
    edited 2014-01-24 06:40
    Mike Petry wrote: »
    Thanks for the fixes, I look forward to the ifdefs for the other model library builds.

    My target hardware isn't a C3, I just use one for testing. It only has eeprom and SPI available for cache. My old code took advantage of the old SD cache driver. The performance wasn't stellar, but acceptable.
    I'm trimming some code and hope to fit all the needed functionality in to the LMM model (That's how I stumbled across the undefines). If it won't fit, I have a few SPI memory chips that I'll try adding to the hardware for cache and move back to the xmm model.

    Thanks Again,
    Mike
    It's possible to get the SD cache driver to work under the new external memory scheme but it will require some work. I encouraged Parallax to abandon the SD cache because of performance issues. You can't read less than 512 bytes at a time from the SD card so cache lines need to be 512 bytes at a minimum and that is too large for a cache line and results in poor performance. If possible, it would be better to add a SPI flash chip to use as external program memory in XMMC model.
Sign In or Register to comment.