Kris
I've found this page to be very helpful over the years.
http://www.zorc.breitbandkatze.de/crc.html

-Bill Knight
R O SoftWare
microbit wrote:
> Hi All,
>
> Has anyone ever worked out what the exact algorithm is for SDIO (1.1 or 2.0) to compute the 7 bit
> CRC in commands ?
> I'm testing with a Spectec SDW-820 802.11b card, and can talk SPI to it fine it seems, I can read
> the OCR and am about to try reading CIS pointer etc.
> However, I'd like to try use SD 1 bit.
>
> As far as I can tell, the polynomial is G(x)= x7+x3+1 but I'm not sure how the CRC itself is
> performed( ie. do you init the CRC with 0 or all ones etc.) Other than that I know that the CRC +
> stop bit + 32 bits of 0 on CMD0 = 0x95, does anyone know how the code should calc the CRC ?
> Is it perhaps the same as a standard CCITT 16 bit calc, except that 7 bits are accumulated?
> I'm actually wondering about the returned 16 bit CRC as well.
>
> B rgds
> Kris

Ok Paul,

Thanks a lot !

Best regards,
Kris

-----Original Message-----
From: A... [mailto:A...] On Behalf Of Paul Curtis
Sent: Tuesday, 24 June 2008 2:25 AM
To: A...
Subject: RE: [AT91SAM] SDIO WLAN 802.11 7 bit CRC calc

Kris,

> Has anyone ever worked out what the exact algorithm is for SDIO (1.1 or
> 2.0) to compute the 7 bit
> CRC in commands ?
> I'm testing with a Spectec SDW-820 802.11b card, and can talk SPI to it
> fine it seems, I can read
> the OCR and am about to try reading CIS pointer etc.
> However, I'd like to try use SD 1 bit.
>
> As far as I can tell, the polynomial is G(x)= x7+x3+1 but I'm not sure
> how the CRC itself is
> performed( ie. do you init the CRC with 0 or all ones etc.) Other than
> that I know that the CRC +
> stop bit + 32 bits of 0 on CMD0 = 0x95,

No. For CRC-7 you do not pour 32 zero bits through for final computation.

> does anyone know how the code should calc the CRC ?

Of course!

> Is it perhaps the same as a standard CCITT 16 bit calc, except that 7
> bits are accumulated?

No, it's not.

> I'm actually wondering about the returned 16 bit CRC as well.

I'll send you the CRC code I wrote.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

Kris,

> Has anyone ever worked out what the exact algorithm is for SDIO (1.1 or
> 2.0) to compute the 7 bit
> CRC in commands ?
> I'm testing with a Spectec SDW-820 802.11b card, and can talk SPI to it
> fine it seems, I can read
> the OCR and am about to try reading CIS pointer etc.
> However, I'd like to try use SD 1 bit.
>
> As far as I can tell, the polynomial is G(x)= x7+x3+1 but I'm not sure
> how the CRC itself is
> performed( ie. do you init the CRC with 0 or all ones etc.) Other than
> that I know that the CRC +
> stop bit + 32 bits of 0 on CMD0 = 0x95,

No. For CRC-7 you do not pour 32 zero bits through for final computation.

> does anyone know how the code should calc the CRC ?

Of course!

> Is it perhaps the same as a standard CCITT 16 bit calc, except that 7
> bits are accumulated?

No, it's not.

> I'm actually wondering about the returned 16 bit CRC as well.

I'll send you the CRC code I wrote.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

Hi All,

Has anyone ever worked out what the exact algorithm is for SDIO (1.1 or 2.0) to compute the 7 bit
CRC in commands ?
I'm testing with a Spectec SDW-820 802.11b card, and can talk SPI to it fine it seems, I can read
the OCR and am about to try reading CIS pointer etc.
However, I'd like to try use SD 1 bit.

As far as I can tell, the polynomial is G(x)= x7+x3+1 but I'm not sure how the CRC itself is
performed( ie. do you init the CRC with 0 or all ones etc.) Other than that I know that the CRC +
stop bit + 32 bits of 0 on CMD0 = 0x95, does anyone know how the code should calc the CRC ?
Is it perhaps the same as a standard CCITT 16 bit calc, except that 7 bits are accumulated?
I'm actually wondering about the returned 16 bit CRC as well.

B rgds
Kris

Things like this happen. However, if you turn your compiler's warning
options full on, they won't get unnoticed.

On Tue, Jun 3, 2008 at 9:47 PM, Did Bacsa wrote:
> Thank you all who tried to help me, I solved the problem.
> Its a shame that I had this mistake which is usually taught on the
> first programming lesson. I used single quotation instead of double
> for the string. (So 'Hello', instead of "Hello").
> Sorry for this mistake (I know its ridiculous), I shouldnt have done it.
>
> regards, David
>
> 2008/6/3 Eric Pasquier :
>
>> David,
>>
>> Below is a piece of code that I am using to display the address of the
>> instruction that cause the Abort.
>> On my board, I have a LCD display, but you can use it and put a breakpoint
>> in the asm part and check r0.
>>
>> By the way, are you sure that your string is '\0' terminated ?
>>
>> Eric
>> ASM Code:
>>
>> //

Thank you all who tried to help me, I solved the problem.
Its a shame that I had this mistake which is usually taught on the
first programming lesson. I used single quotation instead of double
for the string. (So 'Hello', instead of "Hello").
Sorry for this mistake (I know its ridiculous), I shouldnt have done it.

regards, David

2008/6/3 Eric Pasquier :
> David,
>
> Below is a piece of code that I am using to display the address of the
> instruction that cause the Abort.
> On my board, I have a LCD display, but you can use it and put a breakpoint
> in the asm part and check r0.
>
> By the way, are you sure that your string is '\0' terminated ?
>
> Eric
> ASM Code:
>
> //

David,

Below is a piece of code that I am using to display the address of the instruction that cause the Abort.
On my board, I have a LCD display, but you can use it and put a breakpoint in the asm part and check r0.

By the way, are you sure that your string is '\0' terminated ?

Eric
ASM Code:

//==============================// Dabt_Handler
// Data Abort Handler
//-------------------------------
.func Dabt_Handler
Dabt_Handler:

// Load PC and SP
subs r0, lr, #8
msr CPSR_c, #MODE_SYS|I_BIT|F_BIT /* switch to System Mode */
mov r1, sp

ldr sp, =_stack_end /* top-of-stack */

// Call display routine
bl DataAbortMgr

// Endless loop
dabt_handler_loop:
b dabt_handler_loop

.size Dabt_Handler, . - Dabt_Handler
.endfunc

C code:

//==============================// DataAbortMgr
//-------------------------------
void DataAbortMgr(uint32_t pc, uint32_t sp)
{
char Buffer[24];

lcd_display(0,0,"DATA ABORT");
sprintf(Buffer, "pc%08Xsp%08X", pc, sp);
lcd_display(1,0,Buffer);
}

----- Original Message -----
From: Did Bacsa
To: A...
Sent: Tuesday, June 03, 2008 3:02 PM
Subject: [AT91SAM] uart, dabort_handler
Hi!

Im a newbie in ARM7, and I have a problem when i use UART on
AT91SAM7X256 uC in CrossWorks 1.7 (my board is an Olimex SAM-EX256).

I can send characters to the PC and it works fine, but if i want to
send a string the program is stuck in dabort_handler in
AT91SAM7_Startup.s.

This is my function for sending stings:

int uart0_puts ( char* s )
{
while ( *s ) uart0_putchar( *s++ );

return 0;
}

As the program reaches the while ( *s ) uart0_putchar( *s++ ); line it
goes directly to the dabort_handler instead of uart0_putchar()
function.
I have tried several uart examples, but it didnt matter which one i
was using the same phenomena happened.
Do you have any idea whats wrong here?

Thanks for your help in advace!

regards,
David

Check that you don't have tx interrupts
enabled and don't handle them [no ISR].

Fredrik

----- Original Message ----
From: Did Bacsa
To: A...
Sent: Tuesday, June 3, 2008 3:47:41 PM
Subject: Re: [AT91SAM] uart, dabort_handler

Thanks for your suggestion.
I checked it, and the pointer points at the same address in the
uart0_puts() function like the one with which I call this function in
the main function.
What else could be the problem?

David

2008/6/3 Paul Curtis :
> Check the pointer going in for validity (it it reasonable?)
> Single step uart0_puts at the instruction level and examine the addresses
> being used.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
>> -----Original Message-----
>> From: A... [mailto:A...] On
>> Behalf Of Did Bacsa
>> Sent: 03 June 2008 14:02
>> To: A...
>> Subject: [AT91SAM] uart, dabort_handler
>>
>> Hi!
>>
>> Im a newbie in ARM7, and I have a problem when i use UART on
>> AT91SAM7X256 uC in CrossWorks 1.7 (my board is an Olimex SAM-EX256).
>>
>> I can send characters to the PC and it works fine, but if i want to
>> send a string the program is stuck in dabort_handler in
>> AT91SAM7_Startup.s.
>>
>> This is my function for sending stings:
>>
>> int uart0_puts ( char* s )
>> {
>> while ( *s ) uart0_putchar( *s++ );
>>
>> return 0;
>> }
>>
>> As the program reaches the while ( *s ) uart0_putchar( *s++ ); line it
>> goes directly to the dabort_handler instead of uart0_putchar()
>> function.
>> I have tried several uart examples, but it didnt matter which one i
>> was using the same phenomena happened.
>> Do you have any idea whats wrong here?
>>
>> Thanks for your help in advace!
>>
>> regards,
>> David
>>
>>

Single step. Really. You know, figure out what is aborting. Data abort ==
bad pointer.

> -----Original Message-----
> From: A... [mailto:A...] On
> Behalf Of Did Bacsa
> Sent: 03 June 2008 14:48
> To: A...
> Subject: Re: [AT91SAM] uart, dabort_handler
>
> Thanks for your suggestion.
> I checked it, and the pointer points at the same address in the
> uart0_puts() function like the one with which I call this function in
> the main function.
> What else could be the problem?
>
> David
>
>
>
> 2008/6/3 Paul Curtis :
> > Check the pointer going in for validity (it it reasonable?)
> > Single step uart0_puts at the instruction level and examine the
> addresses
> > being used.
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
> >
> >> -----Original Message-----
> >> From: A... [mailto:A...] On
> >> Behalf Of Did Bacsa
> >> Sent: 03 June 2008 14:02
> >> To: A...
> >> Subject: [AT91SAM] uart, dabort_handler
> >>
> >> Hi!
> >>
> >> Im a newbie in ARM7, and I have a problem when i use UART on
> >> AT91SAM7X256 uC in CrossWorks 1.7 (my board is an Olimex SAM-EX256).
> >>
> >> I can send characters to the PC and it works fine, but if i want to
> >> send a string the program is stuck in dabort_handler in
> >> AT91SAM7_Startup.s.
> >>
> >> This is my function for sending stings:
> >>
> >> int uart0_puts ( char* s )
> >> {
> >> while ( *s ) uart0_putchar( *s++ );
> >>
> >> return 0;
> >> }
> >>
> >> As the program reaches the while ( *s ) uart0_putchar( *s++ ); line
> it
> >> goes directly to the dabort_handler instead of uart0_putchar()
> >> function.
> >> I have tried several uart examples, but it didnt matter which one i
> >> was using the same phenomena happened.
> >> Do you have any idea whats wrong here?
> >>
> >> Thanks for your help in advace!
> >>
> >> regards,
> >> David
> >>
> >>
> >>
> >>