Lpc2000

Hi Brendan,
Yep, that's the point I'm at as I have had several other episodes in the 
past all revolving the halfword access. All the standard stuff with 
halfword boundaries etc etc are all in order, as that sort of stuff is 
routine. So the problem is not really this bit of code, it just happens 
to be the latest gremlin to pop up and yes!, through experience I do 
suspect the silicon.

But really it's not a drama anyway as it is easy enough to work around. 
The fact that I am constantly having to work around it is the worry though.

*Peter*


brendanmurphy37 wrote:
> Peter,
>
> Point taken. My own point was directed mroe at Jerome, who seems to 
> want to go from an all-'C' environment to one with more assembler. No 
> problem, if it's a learning experience, but a poor general strategy 
> I'd argue (due to the far greater debug time required).
>
> As for your own issue, I think it pretty unlikely there's some 
> undetected issue with ARM.
>
> What value is "kbwr" by the way?
>
> Also, what is the absolute address of the buffer?
>
> I'd look carefully at the code that unloads the buffer: maybe the 
> problem is there?
>
> Is this code running with any other code that could be corrupting the 
> buffer? Can you produce a system with just this code in it, with 
> nothing else? does it behave the same?
>
> Are higher priority interrupts enabled for the duration of the code 
> you show?
>
> Do you have an ICE that can look at data in memory?
>
> Other things to look at would be to store the incoming data into a 
> 2nd buffer (i.e. do both types of store in parallel) and see do the 
> data match.
>
> Maybe you've done all of these, or their equivalents. Until you've 
> done all the normal investigations and have a very short program 
> (i.e. a total system) that exhibits some unknown behaviour, I 
> wouldn't see a need to question something as basic as ability to 
> execute halfword stores. But then maybe this is the stage you're at?
>
> Brendan