Can't Access AHB SRAM on LPC4350 at adress 0x20004000

[gregdunn]

I have an LPC4350 based board that came in for repair.  I have discovered that you cannot read/write internal AHB SRAM address 0x20004000 to 0x20007FFF.  The processor issues a hard fault when code tries to access this memory area.  Using the IAR IDE memory window, you only see "--" in this memory range.  Other memory ranges seem to work fine.  Any ideas on what may be wrong?  Just a failed part???

[rolfmeeser]

Can you access the SRAM at 0x20008000?

What values do you read from the following word addresses:

0x40045000 ?

0x40043108 ?

0x40043F00 ?

[gregdunn]

Thank you very much for your response.

I can access SRAM at 0x20008000.  You can see where I tested below.

As far as I can tell all SRAM that should be in the LPC4350 is accessible except for the 0x20004000 to 0x20007FFF range.

Here is the information on the register values you requested:

OTP Regs:

I noticed that the part id is returned as 0xA0020830.  This is an LPC4350FET256 should it not be 0xA0000830 like shown in the manual.  Here is a picture of the part:

CREG

I see that the manual shows CREG1 at 0x40043008,  In the IAR iolpc4350_m4.h file, it is addressed at 0x40043108:

__IO_REG32(    CREG_CREG1,            0x40043108,__READ       );

Is this an error in the UM10503 Rev 2.1 manual?

Here is the CREG register view in IAR:

What register is at 0x40043F00.?  I couldn't find that in the documentation.

Thanks,

Greg Dunn

[rolfmeeser]

CREG1 is at address 0x40043008, so the user manual has it right. Looks like a typo in IAR's register definition.

The registers at 0x40043108 and 0x40043F00 are both not officially documented. What they tell us here is that the device's SRAM at 0x20000000 is indeed configured for 16 KiB only!

You've already noticed the apparent root cause of this issue: The part ID is different from the expected ID. The faulty device has bit 17 set, and what this bit does is tell the ROM boot code to limit the available RAM at 0x20000000 to 16 KiB.

This is a revision C silicon sample, and it is potentially affected by the OTP.2 erratum. Certain conditions must be met by the power ramping in the application, or accidental programming of OTP bits may occur. My best guess is that this is what happened to word 0 in OTP bank 0 (part ID) of this device.

With silicon revision D the OTP.2 issue should be gone. For existing boards you should compare the actual power ramping on your board with the conditions described in the errata sheet to evaluate the risk of further failures in the field.

Regards,

Rolf

[gregdunn]

Rolf,

Thank you for your response.  This makes a lot of sense.  I would like to discuss a few other possibly related issues that we have seen with the LPC4350.  Could you possibly send me a personnel email to continue this discussion?

Thanks,

Greg

[rolfmeeser]

I have no access to your email address, so just drop me a note at <firstname>.<lastname>(a)nxp.com