This morning, I started trying to bring up my little AGROS test program on the LPC2387.
It took a while to get the clock initialization right, and I discovered something cute: if your initialization code messes up the clocking (like, by switching to the crystal without first enabling the oscillator), the JTAG debugger can no longer talk to the chip. Fortunately, the errant program can be erased via ISP, after which the JTAG works again.
Now various things are still FUBAR; I suspect one of them is that I'm not initializing the divider control registers for all the peripherals, so probably the UARTs are running at altogether the wrong speed. (I guess I'll just fill in arbitrarily usable values for now, and worry about how the config program should handle them later.)
Meanwhile, it looks like Project Egbert (barely begun) has already aquired a fun follow-on, using a latent capability that I planned into the hardware design on the notion that it might be needed someday. AGROS doesn't support that capability yet, but adding that was on my personal to-do list anyway. So, I guess I'll be usefully busy the rest of the year, assuming that deal goes through.
Update: two clocking-related problems. The PCLKSEL0/1 registers did indeed need filling in... and it says in the fine print that the M and N values in PLLCFG are actually M-1 and N-1. Now the monitor signs on, at the correct Baud rate.
Something else isn't working, possibly in the area of I/O initialization, but that shouldn't be too much of a pain to sort out, now that the CPU and peripheral clocks are getting initialized properly.
Update 2: D'OH! The LPC23xx vectored interrupt controller is different. Better, I think... but definitely different. Gotta add some family-specific #ifdefs to the header file and the code that deals with the VIC. (Maybe not family-specific. Maybe add a definition for ENHANCED_VIC or something, to be set in the config file.)
Anyway, not bad progress for a day when I took an early-afternoon nap and then went to a movie, generally not spending much time on actual work. (Tomorrow, now... tomorrow had better be a solid work day. Which means I'd better get a good night's sleep.)
Update 3: Glermf! Turns out the 32-vector VIC has some rather basic differences in how it works. In particular, the 16 vector control registers, used to map some subset of 32 interrupt sources onto the 16 possible priority levels with associated vectors, have been replaced by 32 vector priority registers, starting at the same address, which (if I'm reading this correctly) merely prioritize the 32 requests, which have a fixed mapping onto the 32 vectors.
Well, that's a much more sensible way to do it, but it means I'll need to put pretty much the entire VIC initialization routine under conditional compilation. I kinda wish NXP's migration document had made this clear; it could saved me a couple of hours.
Update 4: Finally! The monitor signs on and responds to commands, so the UART interrupt must be working... along with the scheduler and whatnot. (I assume the timer interrupt is also getting through.)
Time to set this aside for the moment and do some billable work.
Update 5: One last (?) flippin' headache. The low byte of P2? The bits that are connected to the LED drivers on the MCB2300 board?
They don't work unless you pull the ETM jumper.
I just spent an hour or so bashing my head against this, thinking I wasn't using the FIO port correctly.
Comments