EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

crossworks and MCB4300

Started by Markus Zingg March 18, 2013
Hi Group,

I'm trying to use a Keil MCB4300 developper board along with crossworks.
I downloaded the LPC4300 support package from Rowley and can create a
little test project just fine. It compiles, but when trying to download
this to the board the message pops up telling me that there is a "Target
processor mismatch" which reads:

The target processor defined in the project (LPC4357) os mpt tje same as
the processor attached to the target interface (Unknown Cortex-M4). Do
you want to continue anyway?

If I choose "YES", the subsequent run of the Reset(4) script errors out
with "cannot stop CPU", however the board somehow responds as all LEDs
go on.

I'm obivousely missing something - but what?

TIA

Markus

An Engineer's Guide to the LPC2100 Series

Hi,

On 18 Mar 2013, at 18:30, Markus Zingg wrote:

> Hi Group,
>
> I'm trying to use a Keil MCB4300 developper board along with crossworks.
> I downloaded the LPC4300 support package from Rowley and can create a
> little test project just fine. It compiles, but when trying to download
> this to the board the message pops up telling me that there is a "Target
> processor mismatch" which reads:
>
> The target processor defined in the project (LPC4357) os mpt tje same as
> the processor attached to the target interface (Unknown Cortex-M4). Do
> you want to continue anyway?

This, I think, indicates that the device ID of the target LPC4357 does not match any *published* LPC43xx device ID. NXP have not always published the device IDs of all devices they release into the field--and this usually means that the devices do not identify when programming (the device ID tells us how much RAM and flash each device has). Recently, the device ID is examined before programming to ensure that the project device and the target device are at least compatible before programming even starts.

>
> If I choose "YES", the subsequent run of the Reset(4) script errors out
> with "cannot stop CPU", however the board somehow responds as all LEDs
> go on.
>

Well, really, no idea. Perhaps you should ask at the help desk where Michael may be able to assist you--I don't have any experience with LPC43xx.

-- Paul.



Hi Paul,

First off, thanks for your (as always) quick response!
Could it be that the second problem is a consequence of the Device Id
not being propperly known? I mean that Crossworks when still continueing
somehow forgets that it should deal with an LPC4357? And, provided I
could figure out WHAT device Id this particular LPC4357 returns, I could
i.e. edit some files to teach Crossworks how to propperly deal with it?

I definately will contact the help desk though.

TIA

Markus

Am 19.03.2013 00:03, schrieb Paul Curtis:
>
> Hi,
>
> On 18 Mar 2013, at 18:30, Markus Zingg > > wrote:
>
> > Hi Group,
> >
> > I'm trying to use a Keil MCB4300 developper board along with
> crossworks.
> > I downloaded the LPC4300 support package from Rowley and can create a
> > little test project just fine. It compiles, but when trying to download
> > this to the board the message pops up telling me that there is a
> "Target
> > processor mismatch" which reads:
> >
> > The target processor defined in the project (LPC4357) os mpt tje
> same as
> > the processor attached to the target interface (Unknown Cortex-M4). Do
> > you want to continue anyway?
>
> This, I think, indicates that the device ID of the target LPC4357 does
> not match any *published* LPC43xx device ID. NXP have not always
> published the device IDs of all devices they release into the
> field--and this usually means that the devices do not identify when
> programming (the device ID tells us how much RAM and flash each device
> has). Recently, the device ID is examined before programming to ensure
> that the project device and the target device are at least compatible
> before programming even starts.
>
> >
> > If I choose "YES", the subsequent run of the Reset(4) script errors out
> > with "cannot stop CPU", however the board somehow responds as all LEDs
> > go on.
> > Well, really, no idea. Perhaps you should ask at the help desk where
> Michael may be able to assist you--I don't have any experience with
> LPC43xx.
>
> -- Paul.
>
>



> First off, thanks for your (as always) quick response!
> Could it be that the second problem is a consequence of the Device Id not
> being propperly known? I mean that Crossworks when still continueing
> somehow forgets that it should deal with an LPC4357? And, provided I could
> figure out WHAT device Id this particular LPC4357 returns, I could i.e.
> edit some files to teach Crossworks how to propperly deal with it?

Short answer: don't think so.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com


The 2024 Embedded Online Conference