Electronics > Microcontrollers

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

(1/2) > >>

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:

--- Quote from: luisr on February 21, 2014, 04:36:09 pm --- 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.
--- End quote ---
Are there any config bits (or "fuses") that may affect the this behaviour?

Navigation

[0] Message Index

[#] Next page