Hello Forum,

I am trying to access peripheral registers on the LPC1768. As an initial test, I tried reading the reset value of the I2SDAO transmit channel which can be found at address 0x400A8000.

I tried running the following code:

pc.printf("i2s: 0x%x\r\n", *((unsigned int *)0x400a8000));

This caused the program to hang and not progress further. I then discovered that just dereferencing memory locations in the APB mapped peripherals (ok, I didn't try them all) caused a similar symptom. What is the recognised way to access register contents for debugging when developing drivers? I tried creating a structure that overlaid with the correct offsets, pointed it at a peripheral's base address, but again, program execution ceased when I dereferenced it. I checked the generated addresses and they all looked good and mapped to the User Manual addresses for the registers I was looking at. If this is a data abort, then how do I get this information while debugging?

I really need to be able to dump register contents for the work I am doing.

Thanks in advance for any help anyone can offer.

It appears that not all of the peripherals are powered up during the startup of the mbed device. If you want to use the I2S device, you will have to power it up first. Section 4.8.9 of the LPC1768 User Manual documents the PCONP register used for this.

This code

    printf("PCONP: 0x%x\n", *((unsigned int *)0x400FC0C4));

gives a result of

PCONP: 0x42887de

which does show the I2S peripheral not being powered up.

This code segment appears to enable the read of the I2S peripheral:

    *(volatile unsigned int*)0x400FC0C4 = 0x0C2887de;
    printf("i2s: 0x%x\r\n", *((unsigned int *)0x400a8000));

Hi Adam,

Thank you for the rapid response. Unfortunately I am away from my dev. environment and will not be able to try your solution until this later afternoon. However your suggestion sounds very sensible indeed and I am looking forward to giving it a whirl. It would be quite difficult to develop a driver blindfold! I realise that this is a case of RTFM, but the manual is, erm, 840 pages long and this nugget is buried deep inside, so apologies for being lazy on this one (I can only work on this after my day job and that is for a couple of hours maximum, so I guessed someone on the forum had run into this before).

Will update when further information is available.

Hope it helps.

That's what this forum is for. The first time I hit this was on a Texas Instruments OMAP processor and it took me hours to find out what was going on. It's manual was over 1000 pages :)

Hi Adam,

I have just had chance to try your fix and indeed it works perfectly. I can read the reset value (0x87E1). I did doubt my sanity yesterday but now it's all systems go!

Thanks again.