Marc,

The cpld is in a 16 bit wide area. you will need to read and write to it from within gdb using commands similar to these:

x /h 0x55600000
set *(short *)0x55600000 = 1

By default gdb will do a 32 bit write, and i suspect the end results of all of the writes you were making was just 0 since bits 0 and 1 control the LEDs.

If you trace the connection to STATUS LED 0 through the schematics for the App board and the Card Engine you will see that it is connected to PB1, so you can just use port B to set the state of STATUS LED 0 .

Regards,
Bruce

I noticed that. It turns out that that isn't the issue.

You can write 0xffffffff to turn them off and 0 to turn them on if you are writing 32 bit words. However, when the system is reset and the LH79520 SMC controller resets it's configuration, the LEDs are inaccessible. I'm not sure if this is because the SMC controller is reset or because there is not yet an SDRAM clock. I've found that the latter is necessary before you can see the SRAM registers.

I'm using the BDI2000 JTAG interface. You can tell it to write to memory on start-up. In order to keep the system stable and to verify that it was a complete reset, I do three things:



The first is just a precaution. The second enables two of the three LEDs. The third clears pending interrupts which was a problem in some instances where timer0 had generated an interrupt.

The thing is, I know that the system is correctly reset when the LEDs are off after a reset. If they are on, I know that LogicLoader has had a chance to initialize the SRAM controller before the BDI2000 stops it executing.

Really, I'm not too concerned anymore. I've got another boot loader working alright. Two of the LEDs are now usable. I haven't traced the schematic to see where the third one is enabled. But, I was hoping that someone at Logic would see fit to document all of this.

Cheers.