Did I damaged one of my LPC4370 or is this a silicon/marking error?

[luisr]

To make long history short... I got two LPC Link 2 boards (both with an LPC4370 microcontroller) I've been trying to use one of them as debug adapter and the other as target (demo) board for development.

After at least two month fighting with this board an openocd I just realized that one of my board has a core missing (or just a TAP interface but not sure)... the lpc4370 comes with 3 cores (one M4 plus 2 M0) but one of my LPC Link 2 only report two interfaces in its JTAG chain (no matter if I use Openocd, JLINKGDBServer, rowley crossworks or lpcxpresso)

my question is: is it possible that I somehow managed to permanently disable the TAP for one of M0 cores? I remember that from the very beginning I wasn't able to "see" the three cores on openocd but since I'm a newbie I might got things messed up.

I posted this issue on LPCWARE forum and found another thread with same issue but neither his thread nor mine got answer on this issue... I stopped messing around with my boards because I'm afraid to damage the other board (which is fine)

As a side note, the board that only report two cores is working fine (as far as I can tell), I can upload dbugger firmwares (cmsis-dap or J-Link) and even got the blinky example working... this made me think that the interface is disabled or the microcontroller was wrongly labeled at factory as an LPC4370 (I read somewhere that the LPC Link 2 was shipped with LPC4350 and 4MB Flash at some point)

The link to my post on LPCWARE FORUM http://www.lpcware.com/content/forum/missing-jtag-tap-interface-one-my-two-lpc-link-2-boards-long-post
     

[AlfBaz]

I found this a little interesting so I had a quick look at the data sheet

On page 1356 of UM10503 you have this


If you then go look at the RGU reset control registers BIT12 (M0_SUB_RST) from reg RESET_CTRL0 and Bit24(M0APP_RST) from reg RESET_CTRL1 seem to be the only 2 reset bits that don't automatically clear thereby needing to be cleared by software.

Apparently they can be set by sources other that software. I'll leave that for you to investigate, I'd start with the errata notes

[luisr]

thanks for the link... unfortunately those registers are for reset the core (or peripheral)... and in order to debug a program on both cortex M0 they need to be released from reset (in order to be able to run or go step by step through instructions) but this has nothing to do with disabled TAP port... and even after releasing both M0s they will put on hold again after resetting the or power cycling the board as per default behavior... though I stand to be corrected if that's no the case

Anyway thanks for the link since I wasn't aware that UM10503 was updated recently (I was using version 1.7), Now doing some research I found that the TAP port IS disabled... on page 129 of UM10503 we can see info about CREG5 control register (address 0x40043118) were is possible to temporarily disable any of the available TAP interfaces by writing 1 to their respective control bit (bit 10 for M0SUBTAPSEL, bit 11 for M4TAPSEL and bit 12 for M0APPTAPSEL)...

Having a look at that register in my board reveals that effectively the TAP interface for M0SUB in one of my board is disabled
on the bad LPC4370 the CREG5 control register is set to 40000670 (1000000000000000000011001110000)
while on the good LPC4370  the CREG5 control register is set to 40000270 (1000000000000000000001001110000)

As you can see bit 10 on the bad lpc4370 is set to 1 which is why is disabled, the weird thing is that according to UM10503 this bits should be 0 after reset or power on but bit 10 is always set to 1. I even tried wrinting 0x40001E70 to that register (to disable all TAP intefaces) and after power cycling the board the CREG5 control register is set to 40000670 again.

Now apparently JTAG will be disabled by default when the AES Keys are programmed... so I need to do more research

Any comment will be appreciated

[abyrvalg]

Older LPC2xxx devices had some conditional jtag disable security functionality in bootrom.

[AlfBaz]

the weird thing is that according to UM10503 this bits should be 0 after reset or power on but bit 10 is always set to 1.

Are there any config bits (or "fuses") that may affect the this behaviour?

[luisr]

Older LPC2xxx devices had some conditional jtag disable security functionality in bootrom.

Yes, but is this case that will permanently disable all JTAG functionality. Plesae read my anwser to Alfbaz below

the weird thing is that according to UM10503 this bits should be 0 after reset or power on but bit 10 is always set to 1.

Are there any config bits (or "fuses") that may affect the this behaviour?

The only thing I found so far is a fuse called JTAG_DISABLE (OTP memory bank 3, word 0, bit 31) on page 38 of UM10503.
Now, on table 15 (page 41) we can read the description for that fuse: "If this bit set, JTAG cannot be enabled by software and remains disabled." according to this description I think its safe to assume that this is a general way to disable all JTAG funtionality, so no way to selectively prevent a tap from being enabled by default. Also I can imply that there's a way to enable JTAG "in software"... but so far I've been unable to find it.

I haven't tried to read the OTP memory but my guess is that fuse is not set since JTAG is enabled by default on the M4 and M0APP...

Still no clue why this is happening  and no comment on the LPCWare forum so far (even for the guy that posted this issue before me on Jan)
Regards

[Jeroen3]

Are there any config bits (or "fuses") that may affect the this behaviour?

Probably in the reserved OTP section.
You can disable cores with otp, thats how the dual cores are born.

Not likely something you can do accidentally unless there is another silicon bug...
Have you checked the errata sheet?

You do know that power and clock to all co-processors need to be enabled by the M3/4?
With a ulink you couldn't connect to the M0 in a lpc4350 unless the M4 had enabled it.

[luisr]

Are there any config bits (or "fuses") that may affect the this behaviour?

Probably in the reserved OTP section.
You can disable cores with otp, thats how the dual cores are born.

Not likely something you can do accidentally unless there is another silicon bug...
Have you checked the errata sheet?

You do know that power and clock to all co-processors need to be enabled by the M3/4?
With a ulink you couldn't connect to the M0 in a lpc4350 unless the M4 had enabled it.

Well, I couldn't find anything about jtag on errata sheet Rev. 6.1 — 22 November 2013.
I will try to create a simple project to setup the clocks and release both M0 from reset, but so far even with keil I'm unable to debug any program through jtag in this LPC Link 2... the debugger is unable to halt the M0 core... I will use SWD and try to enable the other cores to see if the missing M0SUB reappears.

Bit sad this is happening but so far this is forcing me to learn... I just ordered a Bambino 210E (Micromint USA) just in case

[luisr]

Just wanted to let you know that the board in question was sent directly to NXP. I'll let you know their verdict