Lpc2000

Hi,

I had some real big problem with the version 1.0c from Keil. But 
with the new version 1.1a it seams like the simulator is working 
correct. Send them an email to get the update link...

//Helge


--- In lpc2000@yahoogroups.com, Alaric B Snell <alaric@a...> wrote:
> 
> Has anyone got a working example of a UART0 receive interrupt 
handler 
> that I could study to see what I'm missing?
> 
> Mine works perfectly within Keil's ARM simulator, but in real 
life, 
> sending a character in on UART0 puts the system in a new random 
state 
> every time! The main loop is outputting characters via the UART, 
so my 
> first thought is that maybe I need to be more careful about 
disabling 
> interrupts ot prevent reading the receive buffer register during 
my 
> main-loop code that loops until the transmit holding register is 
empty 
> then outputs a character.
> 
> It's all written in assembly language, so none of the usual 
> gcc-being-too-smart issues here...
> 
> An earlier run-in with code that worked fine in simulator and died 
in 
> real life concerned the simulator assuming I had more RAM than I 
had, 
> and not throwing a data abort when I accessed outside of it - so I 
now 
> have a seperate handler for each ARM vector, plus a default VIC 
vector, 
> all of which put a different pattern on my test LEDs so I can tell 
it's 
> happened. My UART0 received interrupt handler should put the 
received 
> char on the LEDs, yet somehow it always makes all the LEDs go on, 
like 
> when the chip is reset.
> 
> I'm starting to wonder if there *is* something in this JTAG 
debugging 
> lark after all ;-) This simulator seems too optimistic - it will 
> correctly reflect the behaviour of a correct program, but will not 
> always correctly reflect the behaviour of an incorrect program. 
Bah! 
> When I was designing a logic simulator for asynchronous processor 
> design, I took every opportunity to make it take worst-case 
estimates 
> for bus settling times and the like, and whenever anything was 
read from 
> in a potentially indeterminate state, it flagged it there and 
then, to 
> root out as many potential problems as possible...
> 
> Background: I'm writing my LPC21xx FORTH, as before mentioned. 
It's now 
> setting the system state up fine and starting executing after 
assembling 
> a few basic words (like EMIT, for now hardcoded to use UART0, 
although 
> at a later date to support swapping in different input/output 
drivers by 
> updating a pointer; I plan to support console over I2C, for 
> multi-processor setups) onto a dictionary list. But I want to have 
an 
> interrupt handler for UART0 that puts characters into a buffer for 
KEY 
> to read, except for Ctrl+C which will reset the stacks and drop 
into the 
> interpreter with the console driver switched to UART0, and Ctrl+R 
which 
> will do same but also reset the wordlist pointer (for when you've 
REALLY 
>   hosed the system) - these are needed because the system will, by 
> default, load a file from a FLASH filesystem on startup and begin 
> executing, so we need a way to force it into a clean working state 
that 
> cannot be overriden.
> 
> ABS