Lpc2000

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

--- In lpc2000@yahoogroups.com, Peter Jakacki <peterjak@...> wrote:
>
> This bit of assembler code is a very simple "quick & dirty" routine 
as 
> far as assembler goes. I don't have any problem coding in ARM 
assembler 
> or any assembler for that matter. My problem is not with the 
routine 
> otherwise I would not have posted.
> 
> I have been having a sneaking suspicion that there is a bug 
elsewhere 
> (silicon?) when performing halfword accesses in ARM mode, that's 
what 
> the original post was about, not any difficulty with assembler. All 
my 
> assembly is done in pure ARM mode as I am never going to run out of 
code 
> space and crippling the code just to save a few bytes seems 
pointless.
> 
> When I have a bit more time to spare I will thoroughly exercise the 
chip 
> in halfword mode and try and find what is happening.
> 
> As for C programming a great deal of the threads on this group seem 
to 
> stem from problems with the compiler not doing what you would 
expect it 
> to. I don't have that problem, assembler is assembler and I can see 
> every instruction.
> 
> 
> Hiho Hiho, back to coding we go.
> 
> *Peter*
> 
> 
> brendanmurphy37 wrote:
> > Jerome/Peter,
> >
> > I think the example below is a very good illustration of why it's 
> > best not to bother with assembler at all, if you can avoid it.
> >
> > Unless you're doing something very unusual, you can get away with 
> > less than about fifty lines of assembler. All you need is:
> >
> > - interrupt vector table and startup (to setup stacks)
> > - IRQ interrupt dispatch stub (there's been a couple of very good 
> > examples of this posted here recently)
> > - maybe a pair of functions to disable/re-enable interrupts
> >
> > Everything else can be in 'C', including the basic environment 
setup 
> > (e.g. copying initialised data, zeroing uninitialised data etc.; 
PLL 
> > setup, VIC, MAM setup, peripheral interrupt handlers etc. etc.).
> >
> > Note that the assembler code mentioned above will typically suit 
for 
> > every system you're working on (i.e. is done once), and can 
typically 
> > be found elsewhere (here for example). 
> >
> > RISC and RISC-like architectures are very much designed around 
the 
> > ideas of utilising optimising compilers to make use of the 
simplified 
> > instruction sets, rather than human programmers.
> >
> > You need some expertise to be able to understand ARM assembler 
> > (mainly an ability to lookup and understand the "ARM ARM" book), 
and 
> > modify it if necessary, but my guess is that there are very few 
ARM 
> > (or MIPS or other RISC) assembler "experts" out there, and 
certainly 
> > no need to become one.
> >
> > All this is just an opinion, though!
> >
> > Brendan
>