AnsweredAssumed Answered

LPCOpen for LPC17xx flaw in IAP libraries

Question asked by Luca Matteini on Mar 22, 2019
Latest reply on Mar 25, 2019 by Alice_Yang

All the calls in IAP library (file "iap.c") have a clear astounding defect: they reserve for result data an uint32_t[4] array, while it's clear from UM10360 (sec. 32.8 IAP commands) as from way older application notes too, that the result array has to have 5 (five) elements.

This is clearly evident when you make a call to IAP for device serial number (command 58), where the result is in four 32-bit values, so since as mentioned in UM10360

Define data structure or pointers to pass IAP command table and result table to the IAP
function:
unsigned long command[5];
unsigned long output[5];

and

The first entry in the output table is
the Return Code, followed by any other results, starting with Result0.

there are 5 words written on return - beyond description, I just tested it to hold true on an LPC1769, five words are written as result.

The supplied function Chip_IAP_ReadUID() is then defective, and shouldn't be used if not patched - I won't go through what happens on stack allocated memory, and how much this is going to be critical or not: it's simply code that can lead to memory corruption and whatever can follow.

What surprises me is that LPCOpen version 2.10 dates back to 2014, and is the one supplied with latest MCUXpresso IDE package: am I the first one to note this?

Outcomes