Lpc2000

Check the new version of the UART code in the files section.  It
now disables global interrupts very breifly in the non-interrupt
uart code.

Regards
-Bill Knight
R O SoftWare


On Tue, 24 Feb 2004 22:14:09 +0000, Alaric B Snell wrote:

redsp@... wrote:

>>a small number of places, and I'll open source it so feel free to port 
>>away, or if you get really desperate, lend me an OKI devel board so I 
>>can do it ;-)

> Hey, if you are at all serious, I can do that.  I have a Cogent eval
> board on the way, they called me today about sending the invoice.  I
> can get another one easily.  It has an ML67Q5003 at 60 MHz with SDRAM,
> Flash, Ethernet and I forget what all on the board.  It comes with a
> monitor in Flash, 

When I've got it working on my LPC, remind me and I'll see what I can 
do. Depends on my workload at the time!

> What are you using for debugging?  Seems like most of the development
> tools are not cheap either.  

I'm doing it the hard way - lacking a JTAG debugger (although I probably 
could set one up since I have a parallel port JTAG thingy for my Lattice 
ISP devices, although I gather it's wired differently to the Wigglers 
and so on people round these parts use), I make my code set and unset 
LEDs at key points.

Right now, I've found that my ISR works fine (ok, I wasn't acking the 
interrupt properly, but easily detected with a 'scope and fixed) as long 
as I'm not outputting characters in my main loop.

Looking at the really nice sample code in the files section that Bill 
Knight pointed me to, I don't see any interrupt disabling or anything 
around the non-interrupt UART output code. Now, since my test loop was 
outputting characters at 9600 baud flat out, it was spending almost all 
of its time looping for the THRE bit to go up so I could put out the 
next byte (FIFO disabled).

Interestingly, the problem that made it crash seemed to be that the VIC 
was returning a garbage vector - if I replace the *raw* IRQ vector with 
code to set the LEDs to a known state, rather than all that LDR PC, PC, 
[-0xFF0] stuff, it would always do so. This is highly interesting, 
especially since I have a valid default vector address in the VIC, too. 
Some problem with overloading the VPB? I'm running the CPU at 60MHz (MAM 
enabled, down to 2 wait states, for maximum performance, just for 
kicks!) with a VPBDIV of 4.

And the same code works when not blatting out characters at 9600 baud.

I'm going to try:

1) Disabling IRQs while reading from the THRE bit (although obviously 
not for the entire wait-until-THRE-set loop), and/or while writing to 
the THR, to see if either help.

2) Compiling up Bill's code and getting it outputting at 9600 baud, non 
stop, with receive interrupt handling enabled, then sending a character 
and seeing what happens.

3) Running things slower - slowing the CPU, making it wait between 
outputting characters, speeding up the VPB, etc.

Failing that, has anyone got an ETM setup? :-)

ABS




Yahoo! Groups Links