Device_id um10360

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Fri Feb 25 13:19:12 MST 2011
In UM10398 and UM10375 DEVICE_ID is defined in Chapter 3 under Register Overview Table.

This table is conspicuously missing in UM10360.

The IAP routine for retrieving the device id uses this address.

I would like to retrieve the device id without going through an IAP call.

What is the DEVICE_ID address and why is the register table not published in UM10360?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Mon Feb 28 13:48:26 MST 2011
This is what I asked NXP tech support:

Thank you very much for contacting NXP Technical Support. On 2/25/2011, we have received the following question from you:
Subject: DEVICE_ID
Description: Related product: Microcontrollers, Cortex-M3 (32-bit), LPC1769
In UM10398 and UM10375 DEVICE_ID is defined in Chapter 3 under Register Overview Table.
This table is conspicuously missing in UM10360.
The IAP routine for retrieving the device id uses this address.
I would like to retrieve the device id without going through an IAP call.
What is the DEVICE_ID address and why is the register table not published in UM10360?
Product Category: Microcontrollers
Product Sub-Category: Cortex-M3 (32-bit)
Project Stage: Prototyping

This is the answer I received:

Solution answer::confused:
The device ID hardware register feature is not available on the LPC176x/5x.
It is available on the LPC13xx and LPC11xx products.
Please let us know if this does not resolve your inquiry. Your ticket will remain closed if we do not hear from you.

I am using the IAP call in my code and not pursuing this matter any further.

Thanks to all,
Larry

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Mon Feb 28 01:10:27 MST 2011

Quote: StephenHawkings
...should work for all LPCs.

That's also part of my wish-list :) But there's no agreement or law about it, or did I oversee that since 2 years?

Quote: StephenHawkings
Does it?

NO: No SYSCON @ LPC17xx. Memory map and peripheral addressing is different. And so you are just guessing or is that code really running with LPC17xx?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Mon Feb 28 01:01:02 MST 2011

Quote: StephenHawkings
...should work for all LPCs.

That's also part of my wish-list :) But perhaps you can inform us about an agreement or law about this ?

Quote: StephenHawkings
Does it?

NO. No SYSCON @ LPC1768. Memory map and peripheral addressing is different.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by StephenHawkings on Mon Feb 28 00:50:13 MST 2011
Yes, and because of this, I pointed to, to use the definitions from the headers. In this way, the routine is transportable to other microcontrollers, and it should work for all LPCs. Does it?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Sun Feb 27 04:23:59 MST 2011

Quote: StephenHawkings
If I check with LPC1114 user-manual, in the table for the Device-IDs the outcome is:

0x0444 102B = LPC1114FBD48/301

which is correct for this used EXPRESSO board.

Good Morning Germany,

we're talking about LPC17xx, so please use LPC17xx manual & LPCXpresso17xx :):)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by StephenHawkings on Sun Feb 27 04:14:43 MST 2011
In semi-host mode, you can do this:

printf("Device ID is %x\n", LPC_SYSCON->DEVICE_ID);

It shall give you the correct ID for every LPC-controller. Running it on an LPC1114 XPRESSO board, I got this back:

[SIZE=2][B]Device ID is 444102b[/B]

If I check with LPC1114 user-manual, in the table for the Device-IDs the outcome is:

0x0444 102B = LPC1114FBD48/301

which is correct for this used EXPRESSO board.

Usually try not to use absolute addresses, your code will be complecated to transfer to another controller. Your code is more portable if you use the definitions from CMSIS or other header files.
[/SIZE]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Sun Feb 27 02:52:43 MST 2011
That was copied from a previous build. Thanks for pointing it out Zero.:o

I'll edit the source above.

No the DEVICE_ID is not there and it's not in the Boot ROM area either.

Hats off to TheFallGuy. That is the explanation I have been waiting for.

Thanks

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Sun Feb 27 02:03:46 MST 2011
You should use the IAP routines where possible:
- they are in ROM and not Flash, and so have no impact on your code size. The instructions for the function call will use no more Flash than the instructions to read a memory location.
- they work across all the LPC family
- they work!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Sun Feb 27 00:42:35 MST 2011

Quote: larryvc

// if (*pDEVID == 0x21163F37) printf("address: %08X value: %08X\n",pDEVID,*pDEVID); // or this much faster

It was worth a try.

Unless anyone else has any ideas I will wait for an answer from NXP tech support.

What are you 'hunting' with this ID? E.T. :confused:

Even if you use a correct ID, it's not there :mad:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Sun Feb 27 00:14:33 MST 2011
If you were referring to the memory browser in LPCXpresso showing question marks I agree.:)

But the following code found values at 0x400FC000 - 0x400FFFFF.

/*
===============================================================================
 Name        : redoctober.c
 Author      : $(author)
 Version     :
 Copyright   : $(copyright)
 Description : Hunt for the elusive DEVICE_ID on LPC17xx
               Uses Semihosting
===============================================================================
*/
#ifdef __USE_CMSIS
#include "LPC17xx.h"
#endif
#include <cr_section_macros.h>
#include <NXP/crp.h>
__CRP const unsigned int CRP_WORD = CRP_NO_CRP ;
#include <stdio.h>
 
int main(void) {
 
 uint32_t SearchAddr, SearchEnd;
 uint32_t * pDEVID;
 SearchAddr = (uint32_t) 0x400FC000;
 SearchEnd =  0x40100000;
 pDEVID = SearchAddr;
 
   while (pDEVID < SearchEnd)
    {
     printf("address: %08X value: %08X\n",pDEVID,*pDEVID);                             //use this
//  if (*pDEVID == 0x26113F37) printf("address: %08X value: %08X\n",pDEVID,*pDEVID);  // or this much faster
  *pDEVID++;
    }
    printf("Finished");
 // Enter an infinite loop, just incrementing a counter
 volatile static int i = 0 ;
 while(1) {
  i++ ;
 }
 return 0 ;
}

It was worth a try.

Unless anyone else has any ideas I will wait for an answer from NXP tech support.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Sat Feb 26 22:21:24 MST 2011

Quote: Zero
Then be surprised :) That's nonsense :D

LPC17xx is different.

A simple 'memory view' can show it.

If you use 'memory view' your debugger will show you there's nothing worth searching for :mad:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Sat Feb 26 20:26:30 MST 2011
The address of DEVICE_ID on the 11xx and 13xx parts is 0x400483F4.

That address is in the system control memory area defined as:

[FONT=Arial][COLOR=#005042][FONT=Arial][COLOR=#005042][FONT=Arial][COLOR=#005042][FONT=Times New Roman][COLOR=#000000]0x40048000 - 0x4004BFFF[/COLOR][/FONT][/COLOR][/FONT][/COLOR][/FONT][/COLOR][/FONT]

[FONT=Arial][COLOR=#005042][FONT=Arial][COLOR=#005042][FONT=Arial][COLOR=#005042][FONT=Times New Roman][COLOR=#000000]On the 17xx parts the system control memory area defined as:[/COLOR][/FONT][/COLOR][/FONT][/COLOR][/FONT][/COLOR][/FONT]

[FONT=Arial][COLOR=#005042][FONT=Arial][COLOR=#005042][FONT=Arial][COLOR=#005042][FONT=Times New Roman][COLOR=#000000]0x400FC000 - 0x400FFFFF[/COLOR][/FONT][/COLOR][/FONT][/COLOR][/FONT][/COLOR][/FONT]

So... maybe the DEVICE_ID for the 17xx parts is in this memory area.

Anybody feel like writing code to search for the values below in that memory area.

0x26113F37 LPC1769
0x26013F37 LPC1768

Zero?:)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Sat Feb 26 17:40:38 MST 2011

Quote: Zero
A simple 'memory view' can show it.

Is there a way to access and view all the memory on the chip, not just flash but also ROM?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Sat Feb 26 16:51:51 MST 2011

Quote: KTownsend
They're definately very different, but they share a number of similarities. The CPUID register is identical, for example, but perhaps this is defined by ARM not NXP, whereas the DEVICEID is likely defined by NXP and will vary in location of whether it's present at all:

DEVICE_ID has to be defined somewhere because the ISP/IAP calls must have an address to get the value from.

Kevin I had tried code similar to yours before using your code. My code was also getting the hardfault. The code is right the address isn't.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ktownsend on Sat Feb 26 16:08:10 MST 2011

Quote: Zero
Then be surprised :) That's nonsense :D

LPC17xx is different.

A simple 'memory view' can show it.

They're definately very different, but they share a number of similarities. The CPUID register is identical, for example, but perhaps this is defined by ARM not NXP, whereas the DEVICEID is likely defined by NXP and will vary in location of whether it's present at all:

// 1343
#define SCB_CPUID (*(pREG32 (0xE000ED00)))
// 1768
#define SCB_CPUID (*(volatile unsigned *)0xE000ED00)

If you're getting a hard fault, obviously the register either doesn't exist or is elsewhere, but I'm a bit surprised none the less. :-)

I can get the device ID from a simple register call on the 1300, but perhaps it simple doesn't exist on the 1700.

UPDATE: 0x40048xxx is definately in the peripheral range on the 17xx (CAN2, etc.), so my little guestimate is obviously compltely wrong.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Sat Feb 26 13:33:33 MST 2011
I submitted a request to NXP tech support yesterday to see if they have any info on this.

I know it is not critical to have this information but NXP should at least be more consistent with the content of the UMs.

Thanks Guys. I will post the reply from NXP when I receive it.

If the Earth was flat and just flipped over at night we would all be in the same time zone:)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Sat Feb 26 13:22:16 MST 2011

Quote: KTownsend
I'd just test the register above (I imagine it's the same) and I'd be really surprised if it doesn't work. Probably just a documentation oversight on NXPs part. There IS a lot of information in the user manuals, so it's easy to overlook something every now and then.

Then be surprised :) That's nonsense :D

LPC17xx is different.

A simple 'memory view' can show it.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Sat Feb 26 12:42:00 MST 2011
Kevin

Am i wrong in assuming that pREG32 is defined as below?

//#define SCB_DEVICEID (*(pREG32 (0x400483F4))) // Device ID
#define SCB_DEVICEID (*((uint32_t *) (0x400483F4))) // Device ID

If I use this

printf("Device ID %X\n\n", SCB_DEVICEID);

I goto the HardFault_Handler()

Obviously I am using this wrong. Perhaps an example snippet would help me understand how you are using this.

By the way I took a look at your web site and the codebase and have found it very insightful. Nice work.

Update:

I found the define of pREG32 in your sysdefs.h and updated my code but still get the hardfault at the printf statement.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ktownsend on Sat Feb 26 06:07:02 MST 2011
I've been using the device id register to identify parts on the 11xx and 13xx with no problems. I don't have a 17xx hooked up in front of me, but my guess is that it will behave identically:

/*  DEVICE_ID (Device ID Register)
    This device ID register is a read-only register and contains the device ID for each
    LPC111x part. This register is also read by the ISP/IAP commands. */
#define SCB_DEVICEID                              (*(pREG32 (0x400483F4)))    // Device ID
#define SCB_DEVICEID_LPC1111_101                  ((unsigned int) 0x041E502B)
#define SCB_DEVICEID_LPC1111_201                  ((unsigned int) 0x0416502B)
#define SCB_DEVICEID_LPC1112_101                  ((unsigned int) 0x042D502B)
#define SCB_DEVICEID_LPC1112_201                  ((unsigned int) 0x0425502B)
#define SCB_DEVICEID_LPC1113_201                  ((unsigned int) 0x0434502B)
#define SCB_DEVICEID_LPC1113_301                  ((unsigned int) 0x0434102B)
#define SCB_DEVICEID_LPC1114_201                  ((unsigned int) 0x0444502B)
#define SCB_DEVICEID_LPC1114_301                  ((unsigned int) 0x0444102B)

I don't think performance is that critical, but using this approach might save a bit of flash compared to going the IAP route ... though this is maybe more important to me since I'm using 32KB parts and need to be careful with every KB.

I'd just test the register above (I imagine it's the same) and I'd be really surprised if it doesn't work. Probably just a documentation oversight on NXPs part. There IS a lot of information in the user manuals, so it's easy to overlook something every now and then.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Fri Feb 25 14:41:56 MST 2011

Quote: Zero
Are you planning a time critical part ID read?

No.

I guess my questions are more about code size difference between an IAP call and direct access through a pointer and also why NXP didn't publish the address as in the other UMs.