Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: [lpc2000] ARM halfword bugs?

2006-03-28 by Peter Jakacki

Hi Paul,
The buffer is 64 bytes and it is not spilling over. It employs a simple 
wraparound and normally I would put some error handling around this but 
it is not a problem as the application is always reading the buffer.

*Peter*

The listing again (slightly tidier)


CPU:   LPC2138/2148
TOOL:  IAR Workbench V4.10B

This works:
-------------------------
 106    0000D85C 0F412DE9     KBISR:  stmfd   sp!,{r0-r3,MP,lr}
 107    0000D860 4084A0E3             ldr     MP,=RAM
 108    0000D864 CC001FE5     kbrdl:  ldr     r0,SPCRc
 109    0000D868 042090E5             ldr     r2,[r0,#SPISR-SPCR]
 110    0000D86C 800012E3             tst     r2,#80h
 111    0000D870 DBE3FF0A             beq     EnableVIC
 112    0000D874 0110A0E3             mov     r1,#1
 113    0000D878 1C10C0E5             strb    r1,[r0,#SPINT-SPCR]
 114    0000D87C 081090E5             ldr     r1,[r0,#SPDR-SPCR]
 115    0000D880 34001FE5             ldr     r0,=kbbuf
 116    0000D884 4030D0E5             ldrb    r3,[r0,#kbwr-kbbuf]
 117    0000D888 002083E0             add     r2,r3,r0
 118    0000D88C 001082E5             str     r1,[r2]
 119    0000D890 043083E2             add     r3,r3,#4
 120    0000D894 3F3003E2             and     r3,r3,#kbbufsz-1
 121    0000D898 4030C0E5             strb    r3,[r0,#kbwr-kbbuf]
 122    0000D89C F0FFFFEA             b       kbrdl  
-------------------------

This doesn't quite work:
-------------------------
 106    0000D85C 0F412DE9     KBISR:  stmfd   sp!,{r0-r3,MP,lr}
 107    0000D860 4084A0E3             ldr     MP,=RAM
 108    0000D864 CC001FE5     kbrdl:  ldr     r0,SPCRc
 109    0000D868 042090E5             ldr     r2,[r0,#SPISR-SPCR]
 110    0000D86C 800012E3             tst     r2,#80h
 111    0000D870 DBE3FF0A             beq     EnableVIC
 112    0000D874 0110A0E3             mov     r1,#1
 113    0000D878 1C10C0E5             strb    r1,[r0,#SPINT-SPCR]
 114    0000D87C 081090E5             ldr     r1,[r0,#SPDR-SPCR]
 115    0000D880 34001FE5             ldr     r0,=kbbuf
 116    0000D884 4030D0E5             ldrb    r3,[r0,#kbwr-kbbuf]
 117    0000D888 002083E0             add     r2,r3,r0
!!!!!!!! THIS LINE IS THE PROBLEM !!!!!!
 118    0000D88C B010C2E1             strh    r1,[r2]
 119    0000D890 023083E2             add     r3,r3,#2
 120    0000D894 3F3003E2             and     r3,r3,#kbbufsz-1
 121    0000D898 4030C0E5             strb    r3,[r0,#kbwr-kbbuf]
 122    0000D89C F0FFFFEA             b       kbrdl  
-------------------------


*Peter*




Paul Curtis wrote:
> How big is your buffer?  To be specific, what value does kbbufsz have?
>
> --
> Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
>
>> -----Original Message-----
>> From: Peter Jakacki [mailto:peterjak@...] 
>> Sent: 28 March 2006 09:03
>> To: lpc2000@yahoogroups.com
>> Subject: [lpc2000] ARM halfword bugs?
>>
>> I came across a glitch in my PS/2 keyboard code where every 
>> 11th keystroke my system would experience some sort of 
>> corruption. I checked the code and I checked the code and 
>> everything looks right (it's assembler). Finally in 
>> desperation I changed the halfword store to buffer into a 
>> full word store and then incremented the index by 4 instead 
>> of 2 and now it works perfectly. The buffer is on a word boundary.
>>
>> Normally I wouldn't bother mentioning all this but I have had 
>> a few other episodes in the past somewhat similar to this 
>> before where I replaced the halfword stores with byte or word 
>> stores and everything works fine again.
>>
>> I suspect the assembler as I have dissected other opcodes 
>> before and from memory I think I found problems in that the 
>> machine code was incorrect.
>>
>> Could it be that there is a bug in the ARM core or the 
>> assembler? Does anyone know of similar problems?
>>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.