Problem with spi-sd-card.c (rtems-4.9.0)

[Joel Sherrill]

Robert S. Grimes wrote:
> Joel Sherrill wrote:
>   
>> Are the addresses and sizes for the heap and
>> workspace reasonable?
>>
>>     
> God, I hope so:
>
>     #define CONFIGURE_EXECUTIVE_RAM_SIZE                  (1024*1024)
>
>   
I meant did the BSP allocate the memory to RTEMS and
the C library in a reasonable way.
>> Are you blowing a stack?
>>
>>     
> I don't think so.
>
> The driver is being manually started in my main init function; here is
> the original stack definition
>
>     #define CONFIGURE_INIT_TASK_STACK_SIZE                (10*1024)
>
> Funny, that worked fine on the 4.9.0 pre-release snapshot, with much of
> my app present.  Now, though, with 4.9.0 snapshot, it doesn't - even
> though I've cut away more stuff for clarity!
>
>   
Is it still before your include of <rtems/confdefs.h>?
> I doubled it to 20k, and it worked - once.  I was about to send this,
> then I decided I should see if that fixed the second issue, and now it
> (still) doesn't work!  I even  went to 40k, and it still exhibits both
> issue 1 and 2.  But anyway, I don't think it is the stack..
>
> So, I'm still stuck with all three issues...
>
> -Bob
>
>   
>> Robert S. Grimes wrote:
>>
>>     
>>> Seems I've moved backwards from last week.  I switched to 4.9.0, and
>>> that seemed fine - until I returned to the SD card driver.  I can't even
>>> get the basic card id functions to work - it fails before then.  Here
>>> are my (current) problems:
>>>
>>> 1. In spi-sd-card.c, sd_card_driver_init, sd_card_driver_get_entry fails
>>> to return pointer to driver.  Specifically, X_get_entry returns an
>>> incorrect value (0x51xxxx, for example, when it should be 0x48xxxx - the
>>> point of these addresses is only to point out the issue).  Then, the
>>> following call to CHECK_RVSC blasts the local variable e, setting it to 2!
>>>
>>> 2. If I manually correct (in the debugger) the value, when later a call
>>> to rtems_io_register_driver is made, the sd_card_disk_ops table only has
>>> an entry for the initialization_entry; all others are 0.
>>>
>>> 3. Finally, the card never leaves the "busy" state, in that the output
>>> line is always low.
>>>
>>> 4. I haven't noticed a CMD0 being sent to the card with the CS low; this
>>> seems to be needed to switch the card to SPI mode.  Am I missing something?
>>>
>>> Any ideas?
>>> -Bob
>>>
>>> P.S. I'm using the powerpc/virtex BSP, and the virtex SPI functions seem
>>> to be called correctly, and the SPI signals at the card seem correct.
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>
>>>
>>>       
>> --
>> Joel Sherrill, Ph.D.             Director of Research & Development
>> joel.sherrill at OARcorp.com        On-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>    Support Available             (256) 722-9985
>>
>>
>>
>>
>>     
>
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985