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

Start a New Thread

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
>
>
>
> Start a New Thread

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
>>
>> Start a New Thread

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
> >>
> >>
> >>
> >> Start a New Thread

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
>>
>> Start a New Thread

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 Start a New Thread

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:
>
> // Start a New Thread

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:
>>
>> // Start a New Thread

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
Start a New Thread

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

Start a New Thread