Reading LPC UID (s/n): different results

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Jaecko on Thu Sep 27 01:26:03 MST 2012
Hello.

When reading the device serial number of an LPC1769, i often get different results when reading repeatedly.
The most common s/n i get is "0808F715-53560F40-4ECD83F7-F5000001", so i assume that this is the correct one.
But sometimes it looks like "00000015-100011E0-00000002-000007FA", "00000015-100011E0-00000001-00000001" or something like "0808F715-53560F40-4ECD83F7-00000001" which has only one byte difference.

How i read the s/n (relevant code) is attached below.

Does somebody know, why i get different results here?

Regards.

static uint32_t IAP_cmd[5];
static uint32_t IAP_res[5];

#define IAPCMD_READ_UID  58
#define IAP_ENTRY_LOCATION  ((IAP_t)0x1FFF1FF1)

#define IAP_ReadUID() \
{ \
  IAP_cmd[0] = IAPCMD_READ_UID; \
  IAP_Execute(); \
}

void IAP_Execute( void )
{
  IAP_ENTRY_LOCATION(IAP_cmd, IAP_res);
}

void IAP_GetUID(uint32_t *uid)
{
  IAP_ReadUID();
  uid[0] = IAP_res[0];
  uid[1] = IAP_res[1];
  uid[2] = IAP_res[2];
  uid[3] = IAP_res[3];
  uid[4] = IAP_res[4];
}


uint32_t tmp32buffer[5];
IAP_GetUID(tmp32buffer); // <= here, elements 1...4 should contain the s/n, 0 is always 0

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Thu Sep 27 10:01:39 MST 2012

Quote: Jaecko
Could it be that the IAP-functions don't like it, when they are bugged by interrupts?

You should protect yout IAP if interrupts are enabled

...
__disable_irq();
iap_entry(param_table,result_table);
__enable_irq();
...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MikeSimmonds on Thu Sep 27 09:09:39 MST 2012
[FONT=Tahoma][SIZE=2]

Quote: Jaecko
Could it be that the IAP-functions don't like it, when they are bugged by interrupts?
The only explanation i have for this...

[/SIZE][/FONT][SIZE=2][FONT=Tahoma]That's exactly the reason.
The IAP read cpuid, read serial, read boot rom version do not use any ram in the 'top 32 bytes' and only 3 levels of stack (12 bytes).

However it works by temporarily mapping a rom area over the first 600 (hex) [or maybe 800] bytes of the flash area.

So if your code is located in low flash -- bang. Also if you have any interrupts whilst the IAP call is in progress the 'fetched' vector is rubbish instead of your handler routine, and again -- bang.

The need to disable or otherwise prevent interrupts during IAP is documented in the UM10360 (for LPC1769), but I admit that like a lot of important issues they don't emphasise it enough.

Fetching the s/n at startup before you enable any interrupts is probably a good idea, but this tells you why you ought to do it.

Regards, Mike
    [/FONT][/SIZE]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Jaecko on Thu Sep 27 07:40:46 MST 2012
Thanks to both of you. But both code samples show the same behaviour.

But: I finally found a way how it works with 100% reliability:
I simply don't read the s/n when the request comes. I do it as first thing in the program (before initialising Timers/UART/...) and store it in an array which is read when requesting the s/n.
Every time the device restarts, the s/n keeps the same; here even without the stack increase.

Could it be that the IAP-functions don't like it, when they are bugged by interrupts?
The only explanation i have for this...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by OXO on Thu Sep 27 05:09:01 MST 2012
This code works all the time. It's based on an app note, but I can't remember which :rolleyes:

// read unique chip id from LPC
// by IAP call
#define IAP_ADDRESS 0x1FFF1FF1
unsigned param_table[5];
unsigned result_table[5];

static void iap_entry(unsigned param_tab[],unsigned result_tab[])
{
   void (*iap)(unsigned [],unsigned []);

   iap = (void (*)(unsigned [],unsigned []))IAP_ADDRESS;
   iap(param_tab,result_tab);
}

void read_serial_number(uint32_t *ptr)    //read serial via IAP
{
   param_table[0] = 58; //IAP command
   iap_entry(param_table,result_table);

   if(result_table[0] == 0) //return: CODE SUCCESS
   {
      printf("Serial Number: %08X %08X %08X %08X\n\r",result_table[1],result_table[2],result_table[3],result_table[4]);
      ptr[0] = result_table[1];
      ptr[1] = result_table[2];
      ptr[2] = result_table[3];
      ptr[3] = result_table[4];
   }
   else
   {
      printf("Serial Number Read Error\n\r");
   }
}

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Thu Sep 27 04:09:45 MST 2012
I'm not familiar with your IAP functions, project settings and don't understand why your array isn't volatile,

but #7 of http://knowledgebase.nxp.com/showthread.php?t=774 shows a working sample :)

If this code is working without problems with LPCXpresso (and stack offset) your code is faulty :eek:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Jaecko on Thu Sep 27 03:16:29 MST 2012
Ah ok, found the chapter (was UM10360).
We have a our own linker script, so the offset had to be placed in the script (_vStackTop = ___top_RamLoc32 - 32; )

But unfortunately this didn't change the behaviour. Same "wrong" s/ns.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Thu Sep 27 02:41:01 MST 2012

Quote: Jaecko
Well, there is no information in the manual to do this.

:confused: Which user manual are you reading :confused:

UM10360:

Quote:

32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack usage in the user allocated stack space is 128 bytes and it grows downwards.

If we are talking about LPCXpresso:

http://www.support.code-red-tech.com/CodeRedWiki/ReserveIAPRam?highlight=%28IAP%29

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Jaecko on Thu Sep 27 02:23:23 MST 2012
Well, there is no information in the manual to do this.
Also in other codes i found is nothing explicitly done with the stack.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Thu Sep 27 01:48:45 MST 2012
First guess: Forgotten to increase stack offset :confused: