LPCOpen LPC15xx IAP Confusion

lpcware · ‎06-15-2016

Content originally posted in LPCWare by LabRat on Fri Aug 29 22:12:41 MST 2014
LPCOpen LPC15xx IAP code is confusing / wrong:

/**
 * @brief LPC15XX IAP_ENTRY API function type
 */
static INLINE void iap_entry(unsigned int cmd_param[5],[color=#f00] unsigned int status_result[4])
{[/color]
((IAP_ENTRY_T) IAP_ENTRY_LOCATION)(cmd_param, status_result);
}

...seems to indicate that the maximum number of results is 4...

UM:

Quote:

The maximum number of results is[color=#f00] 5[/color], returned by the "ReadUID" command.

And trying to use Chip_IAP_ReadUID is showing the promised problem:

/* Read the unique ID */
uint32_t Chip_IAP_ReadUID()
{
uint32_t command[5],[color=#f00] result[4][/color];

command[0] = IAP_READ_UID_CMD;
iap_entry(command, result);

return result[1];
}

IAP ReadUID is returning Status code, Result0-Result3, so here's a result[5] required

I'm not sure why result[1] is returned here (alcohol?), of course a pointer would be an easy solution...

/* Read the unique ID */
uint32_t Chip_IAP_ReadUID(uint32_t* serial_number)
{
 uint32_t command[5];

 command[0] = IAP_READ_UID_CMD;
 iap_entry(command, (uint32_t*)serial_number);

 return (uint32_t)(*(serial_number));//return status code
}

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mc on Mon Aug 10 16:44:04 MST 2015
Hi All,
Thanks for the feedback. The issue related to the size of result[] array has been added to tracker.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Fri Jul 24 03:22:51 MST 2015

Quote: miccio
Anyways, I cannot be neither optimist nor pessimist, since I'm using lpc11Cxx :bigsmile:

:bigsmile:

Then sooner or later a new LPC15 is on your Christmas wish list...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by miccio on Fri Jul 24 01:52:11 MST 2015
I found that thread few minutes after i sent yesterday's message, and it was the first time I've heard of this alleged 3rd version.
Funny enough, when embracing LPCXpresso I first thought that LPCOpen was a community-driven effort (it bears a somewhat misleading name, doesn't it?) rather than the result of NXP's internal development.
I think everyone would benefit from such a shift in responsibility.

Anyways, I cannot be neither optimist nor pessimist, since I'm using lpc11Cxx :bigsmile:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Thu Jul 23 20:42:29 MST 2015

Quote: miccio
Which makes me wonder, is there ever going to be a newer version of LPCOpen?

Good question :)

https://www.lpcware.com/content/forum/should-i-update-217-when-using-111x

is including a vague hint:

Quote:
To date, LPCOpen releases have been primarily to add support for devices and boards, with bug fixes along the way. We are putting systems in place to provide more responsive bug fix updates across our products. The first results of these new systems should be integrated into our [color=#f00]standard release flow by the end of this year for some devices[/color], and then roll out across the rest of the Cortex families.

So some optimists here think that there's a new LPC15xx LPCOpen version available in summer 2016 :)

Pessimists are assuming that we still have to work with our own version 2 years after LPC15xx series release :(

lpcware · ‎06-15-2016

Content originally posted in LPCWare by miccio on Thu Jul 23 16:56:03 MST 2015

Quote:

What's making this code better than LabRat's solution?

Nothing in particular, I just wanted to add to the records that they got around to fix the issue pointed out in this post in the latest version of LPCOpen (which is only available for the 112x family) :)

Which makes me wonder, is there ever going to be a newer version of LPCOpen?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Thu Jul 23 04:14:14 MST 2015

Quote: miccio
...it seems like the best IAP implementation is provided in the lpc112x issue of LPCOpen...

:~

What's making this code better than LabRat's solution?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by miccio on Thu Jul 23 03:43:01 MST 2015
Little heads up for whoever had the same issue with LPCOpen for other MCUs: it seems like the best IAP implementation is provided in the lpc112x issue of LPCOpen:

uint32_t Chip_IAP_ReadUID(uint32_t* uid)
{
uint32_t command[5], result[5];
uint32_t i;

command[0] = IAP_READ_UID_CMD;
iap_entry2(command, result);

for (i=0; i<4; i++)
*(uid+i) = result[i+1];

return result[0];
}

lpcware · ‎06-15-2016

Content originally posted in LPCWare by 1234567890 on Sun Aug 31 05:26:52 MST 2014
Yes, that's definately right.
This bug seems to be known (at least to parts of staff) because in iap_8h_source.html is a FIXME reminder for that.