topic Re: Flash frustrations in LPC Microcontrollers

Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:29 GMT

Content originally posted in LPCWare by JohnR on Tue Apr 24 06:05:44 MST 2012
Hi,

I am getting thoroughly fed up with trying to flash the memory on my Diolan board using LPC-Link.

I seem to be able to flash reliably if the start address is the start of flash memory. But I want to be able to store the M3 axf file as well as the M0 file to flash. So if put the M3 at the start having partitioned the memory to be split in two, the M3 code works fine.

But then if I want to use a different start address for M0 at 0x1c100000, LENGTH = 0x100000, I almost always get the error message

Ec: Flash driver command failure 100003F0, 2

Occasionally it has seemed to work.

I have searched for a list of definitions of the flash driver error codes - is such a list available?

Thanks in advance for any help.

JohnR

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:30 GMT

Content originally posted in LPCWare by PhilYoung on Tue Apr 24 07:24:11 MST 2012
sounds a bit suspicious as the address is not in the image you are trying to program for the M0 image.

I suspect that what it's trying to do is insert the CRC required by the boot loader, this is created by the linker and inserted automatically.

the error would then be because it couldn't program the CRC as that area has not been erased.

this is the only explanation I can think of, that the CRC is not being inserted at the correct address for the M0 image.

regards

Phil.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:30 GMT

Content originally posted in LPCWare by JohnR on Tue Apr 24 08:55:58 MST 2012
Thanks so much for the reply.

What is meaning of the line Ec: Flash driver command failure 100003F0, 2 ??

If this is an address, we shouldn't be near there as we are starting at 1c100000? The program is only 1440 bytes long.

The strange thing that it has seemed to load and run OK sometimes but I can never reproduce the success on command.

I'll try anything at this stage so any more ideas are welcome.

Thanks

JohnR

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:31 GMT

Content originally posted in LPCWare by PhilYoung on Tue Apr 24 11:31:29 MST 2012
Hi John,
I assume you noticed that after power up not all EMC address lines are enabled by theboot loader, so you have to enable the additional address lines to the flash in order to be able to access more than 64K bytes.

I am successfully running code on the M0 at 0x1c040000, to do this I actually build the image so that is both the load and execution address for the startup code.
On the M4 I then set the shadow address for the M0 to be 0x1c040000 so the M0 fetches the stack pointer and PC from 0x00000000,0x00000004 then immediately starts executing code from the flash rather than the shadow area.

this ensures that the CRC etc are correctly located by the programmer.

I then set the execution address for the main app to be in internal ram and let the boot loader relocate it.

I presume that you are using the M4 to program the image, since the M0 may not be enabled.

I also modified the progammer code to use a different flash device and added code to the startup to set up the EMC address lines correctly, I don't know what programmer you are using but it's possible that it doesn't do this in which case you need to use a script.

the effect of this is if the device has been reset before you program it the EMC address lines may not be enabled which would explain why programming may be intermittent.

this is the code I use for setting up the EMC which should be placed in the .ini file

FUNC void emc_setup (void) {
_WDWORD(0x4005006c, 0x01000800); // base m4 clk to IRC
_WDWORD(0x4008609C, 0x000000f3); /* P1_7: D0 (function 3) */
_WDWORD(0x400860A0, 0x000000f3); /* P1_8: D1 (function 3) */
_WDWORD(0x400860A4, 0x000000f3); /* P1_9: D2 (function 3) */
_WDWORD(0x400860A8, 0x000000f3); /* P1_10: D3 (function 3) */
_WDWORD(0x400860AC, 0x000000f3); /* P1_11: D4 (function 3) */
_WDWORD(0x400860B0, 0x000000f3); /* P1_12: D5 (function 3) */
_WDWORD(0x400860B4, 0x000000f3); /* P1_13: D6 (function 3) */
_WDWORD(0x400860B8, 0x000000f3); /* P1_14: D7 (function 3) */
_WDWORD(0x40086280, 0x000000f2); /* P5_0: D12 (function 2) */
_WDWORD(0x40086284, 0x000000f2); /* P5_1: D13 (function 2) */
_WDWORD(0x40086288, 0x000000f2); /* P5_2: D14 (function 2) */
_WDWORD(0x4008628C, 0x000000f2); /* P5_3: D15 (function 2) */
_WDWORD(0x40086290, 0x000000f2); /* P5_4: D8 (function 2) */
_WDWORD(0x40086294, 0x000000f2); /* P5_5: D9 (function 2) */
_WDWORD(0x40086298, 0x000000f2); /* P5_6: D10 (function 2) */
_WDWORD(0x4008629C, 0x000000f2); /* P5_7: D11 (function 2) */
_WDWORD(0x40086688, 0x000000f2); /* PD_2: D16 (function 2) */
_WDWORD(0x4008668C, 0x000000f2); /* PD_3: D17 (function 2) */
_WDWORD(0x40086690, 0x000000f2); /* PD_4: D18 (function 2) */
_WDWORD(0x40086694, 0x000000f2); /* PD_5: D19 (function 2) */
_WDWORD(0x40086698, 0x000000f2); /* PD_6: D20 (function 2) */
_WDWORD(0x4008669C, 0x000000f2); /* PD_7: D21 (function 2) */
_WDWORD(0x400866A0, 0x000000f2); /* PD_8: D22 (function 2) */
_WDWORD(0x400866A4, 0x000000f2); /* PD_9: D23 (function 2) */
_WDWORD(0x40086714, 0x000000f3); /* PE_5: D24 (function 3) */
_WDWORD(0x40086718, 0x000000f3); /* PE_6: D25 (function 3) */
_WDWORD(0x4008671C, 0x000000f3); /* PE_7: D26 (function 3) */
_WDWORD(0x40086720, 0x000000f3); /* PE_8: D27 (function 3) */
_WDWORD(0x40086724, 0x000000f3); /* PE_9: D28 (function 3) */
_WDWORD(0x40086728, 0x000000f3); /* PE_10: D29 (function 3) */
_WDWORD(0x4008672C, 0x000000f3); /* PE_11: D30 (function 3) */
_WDWORD(0x40086730, 0x000000f3); /* PE_12: D31 (function 3) */

_WDWORD(0x40086124, 0x000000f3); /* P2_9: A0 (function 3) */
_WDWORD(0x40086128, 0x000000f3); /* P2_10: A1 (function 3) */
_WDWORD(0x4008612C, 0x000000f3); /* P2_11: A2 (function 3) */
_WDWORD(0x40086130, 0x000000f3); /* P2_12: A3 (function 3) */
_WDWORD(0x40086134, 0x000000f3); /* P2_13: A4 (function 3) */
_WDWORD(0x40086080, 0x000000f2); /* P1_0: A5 (function 2) */
_WDWORD(0x40086084, 0x000000f2); /* P1_1: A6 (function 2) */
_WDWORD(0x40086088, 0x000000f2); /* P1_2: A7 (function 2) */
_WDWORD(0x40086120, 0x000000f3); /* P2_8: A8 (function 3) */
_WDWORD(0x4008611C, 0x000000f3); /* P2_7: A9 (function 3) */
_WDWORD(0x40086118, 0x000000f2); /* P2_6: A10 (function 2) */
_WDWORD(0x40086108, 0x000000f2); /* P2_2: A11 (function 2) */
_WDWORD(0x40086104, 0x000000f2); /* P2_1: A12 (function 2) */
_WDWORD(0x40086100, 0x000000f2); /* P2_0: A13 (function 2) */
_WDWORD(0x40086320, 0x000000f1); /* P6_8: A14 (function 1) */
_WDWORD(0x4008631C, 0x000000f1); /* P6_7: A15 (function 1) */
_WDWORD(0x400866C0, 0x000000f2); /* PD_16: A16 (function 2) */
_WDWORD(0x400866BC, 0x000000f2); /* PD_15: A17 (function 2) */
_WDWORD(0x40086700, 0x000000f3); /* PE_0: A18 (function 3) */
_WDWORD(0x40086704, 0x000000f3); /* PE_1: A19 (function 3) */
_WDWORD(0x40086708, 0x000000f3); /* PE_2: A20 (function 3) */
_WDWORD(0x4008670C, 0x000000f3); /* PE_3: A21 (function 3) */
_WDWORD(0x40086710, 0x000000f3); /* PE_4: A22 (function 3) */

_WDWORD(0x40086094, 0x000000f3); /* P1_5: CS0 (function 3) */
_WDWORD(0x400866B0, 0x000000f2); /* PD_12: CS2 (function 2) */
_WDWORD(0x40086098, 0x000000f3); /* P1_6: WE (function 3) */
_WDWORD(0x4008608C, 0x000000f3); /* P1_3: OE (function 3) */
_WDWORD(0x40086090, 0x000000f3); /* P1_4: BLS0 (function 3) */
_WDWORD(0x40086318, 0x000000f1); /* P6_6: BLS1 (function 1) */

_WDWORD(0x40086324, 0x000000f3); /* P6_9: DYCS0, function 3 */
_WDWORD(0x40086310, 0x000000f3); /* P6_4: CAS, function 3 */
_WDWORD(0x40086314, 0x000000f3); /* P6_5: RAS, function 3 */
_WDWORD(0x4008632C, 0x000000f3); /* P6_11: CKEOUT0, function 3 */
_WDWORD(0x40086330, 0x000000f3); /* P6_12: DQMOUT0, function 3 */
_WDWORD(0x40086328, 0x000000f3); /* P6_10: DQMOUT1, function 3 */

   /* initialise the EMC */
_WDWORD(0x40005000, 0x00000001);      /* Enable */
_WDWORD(0x40005200, 0x00000081);      /* CS0: 16 bit, WE */
_WDWORD(0x40005208, 0x00000001);      /* CS0: WAITOEN = 1 */
_WDWORD(0x4000520C, 0x00000006);      /* CS0: WAITRD = 6 */

_WDWORD(0x40005240, 0x00000081);      /* CS2: 16 bit, WE */
_WDWORD(0x40005248, 0x00000001);      /* CS2: WAITOEN = 1 */
_WDWORD(0x4000524C, 0x00000006);      /* CS2: WAITRD = 6 */
}

_sleep_(100);

emc_setup();

regards

Phil.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:32 GMT

Content originally posted in LPCWare by JohnR on Tue Apr 24 17:12:06 MST 2012
Hi Phil,

Thanks so much for your useful reply.

You wrote - I presume that you are using the M4 to program the image, since the M0 may not be enabled.

Actually I have M0 and M4 as two separate projects in LPCXpresso, hoping to load them into separate ranges in flash. The code was based on an example from Diolan.

When I wrote last I was having problems with the flash loader but now I have got a shorter cable that _seems_ to have cured that problem. I have also used now the lower ranges of the flash.

At the present, the M4 code runs from flash but not the M0 which is mapped into a higher range of the flash. The same M0 code runs in RAM okay but loading this via LPC_Link seems to shut down M4.

It would be nice if there was an LPCXpresso version of a dual M4/M0 project as a starting point.

John.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:32 GMT

Content originally posted in LPCWare by JohnR on Tue Apr 24 17:25:56 MST 2012
Hi Phil,

I have just reversed the order of M4 and M0 in the flash and now M0, which is now at the lower address,runs but not M4!

How ever does one get both running at the same time?

John

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:33 GMT

Content originally posted in LPCWare by PhilYoung on Fri Apr 27 01:00:02 MST 2012
Hi John,
not sure what you mean by shuts down the M4.
To program flash you have to avoid anything else reading the flash at the same time, so the other processor needs to be prevented from executin code from or accessing flash.

by default the M0 is not running until the M4 enables the clock to it, so I always use the M4 for programming.

I'm successfully running both devices booting from flash, the only thing I needed to do to enable this was enable the additional address lines as they are not all enabled after the boot loader executes.

I didn't use the dual boot example code so can't comment on whether it works though.

I guess if you program them separately as 2 projects you remembered to set the flash programmer to just erase the required sections rather than the whole device!.

regards

Phil.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:34 GMT

Content originally posted in LPCWare by JohnR on Fri Apr 27 04:53:10 MST 2012
Hi Phil,

Thanks yet again for the useful comments - maybe you could write "The Definitive Guide to the LPC4300 Arm Cortex M4/M0"?

Re your final remark - I usually erased the whole device before programing the two sections.

John.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:34 GMT

Content originally posted in LPCWare by PhilYoung on Fri Apr 27 06:26:58 MST 2012
Hi John,
So after programming the 2 sections have you tried using the debugger to view the flash contents?.

How are you connected to the device?, if you are using the Jtag interface do you close the second debugger before programming as this can also cause interference, particularly if periodic refresh is enabled.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:35 GMT

Content originally posted in LPCWare by JohnR on Fri Apr 27 09:12:22 MST 2012
Hi Phil,

I am using the 4-wire SWD over a LPC_Link card connected to the 10-pin JTAG connector on the Diolan card.

The debugger seems to work fine if the flash starting address is 0xC0 but not if I use any other starting address - it seems that it only reads from 0x0. If I run the debugger after loading a program with a non-zero address, it appears to load but if the program is stopped, no C code is displayed and the assembly window shows whatever happens to be in, I think, the equivalent zero-based offset.

John.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:35 GMT

Content originally posted in LPCWare by PhilYoung on Sat Apr 28 03:50:00 MST 2012
I'm getting slightly confused now what you are trying to do.
If you load code to flash and then try to execute it with the debugger it will of course try executing from the base of the flash.
The M0 and M4 both load the SP and PC from 0, so each of them has a shadow register which controls what address is actually mapped to 0.

If you want to use the debugger to debug an image that is not at the base of flsah then you need to use the debugger command window or a script to first enable the additional address pins, then set the shadow register before letting the CPU Run.

As the CPU will not be issued a reset you then need to manually load SP from 0x0 and PC from 0x4, this will simulate the load that the CPU does at startup following a HW reset.

Instead of this I usually just link the code so that the startup is executed from the flash address, and load SP / PC from the start of the image, that way it doesn't matter about the shadow register.

regards

Phil.

below is my .ini file for Keil, you would need to make some small changes,i.e. object file name.
You may need to re-code this for your development environment.

FUNC void M4 (void) {
SP = _RDWORD(0x1C000000);                          // Setup Stack Pointer
PC = _RDWORD(0x1C000004);                          // Setup Program Counter
_wdword(0x40043100,0x1c000000);// shadow M4 address
}

FUNC void Jump (void) {
PC = 0x1C000001;                          // Setup Program Counter
}

FUNC void M0 (void) {
SP = _RDWORD(0x1C040000);                          // Setup Stack Pointer
PC = _RDWORD(0x1C040004);                          // Setup Program Counter
_wdword(0x40043404,0x1c040000);
}

FUNC void emc_setup (void) {
_WDWORD(0x4005006c, 0x01000800); // base m4 clk to IRC
_WDWORD(0x4008609C, 0x000000f3); /* P1_7: D0 (function 3) */
_WDWORD(0x400860A0, 0x000000f3); /* P1_8: D1 (function 3) */
_WDWORD(0x400860A4, 0x000000f3); /* P1_9: D2 (function 3) */
_WDWORD(0x400860A8, 0x000000f3); /* P1_10: D3 (function 3) */
_WDWORD(0x400860AC, 0x000000f3); /* P1_11: D4 (function 3) */
_WDWORD(0x400860B0, 0x000000f3); /* P1_12: D5 (function 3) */
_WDWORD(0x400860B4, 0x000000f3); /* P1_13: D6 (function 3) */
_WDWORD(0x400860B8, 0x000000f3); /* P1_14: D7 (function 3) */
_WDWORD(0x40086280, 0x000000f2); /* P5_0: D12 (function 2) */
_WDWORD(0x40086284, 0x000000f2); /* P5_1: D13 (function 2) */
_WDWORD(0x40086288, 0x000000f2); /* P5_2: D14 (function 2) */
_WDWORD(0x4008628C, 0x000000f2); /* P5_3: D15 (function 2) */
_WDWORD(0x40086290, 0x000000f2); /* P5_4: D8 (function 2) */
_WDWORD(0x40086294, 0x000000f2); /* P5_5: D9 (function 2) */
_WDWORD(0x40086298, 0x000000f2); /* P5_6: D10 (function 2) */
_WDWORD(0x4008629C, 0x000000f2); /* P5_7: D11 (function 2) */
_WDWORD(0x40086688, 0x000000f2); /* PD_2: D16 (function 2) */
_WDWORD(0x4008668C, 0x000000f2); /* PD_3: D17 (function 2) */
_WDWORD(0x40086690, 0x000000f2); /* PD_4: D18 (function 2) */
_WDWORD(0x40086694, 0x000000f2); /* PD_5: D19 (function 2) */
_WDWORD(0x40086698, 0x000000f2); /* PD_6: D20 (function 2) */
_WDWORD(0x4008669C, 0x000000f2); /* PD_7: D21 (function 2) */
_WDWORD(0x400866A0, 0x000000f2); /* PD_8: D22 (function 2) */
_WDWORD(0x400866A4, 0x000000f2); /* PD_9: D23 (function 2) */
_WDWORD(0x40086714, 0x000000f3); /* PE_5: D24 (function 3) */
_WDWORD(0x40086718, 0x000000f3); /* PE_6: D25 (function 3) */
_WDWORD(0x4008671C, 0x000000f3); /* PE_7: D26 (function 3) */
_WDWORD(0x40086720, 0x000000f3); /* PE_8: D27 (function 3) */
_WDWORD(0x40086724, 0x000000f3); /* PE_9: D28 (function 3) */
_WDWORD(0x40086728, 0x000000f3); /* PE_10: D29 (function 3) */
_WDWORD(0x4008672C, 0x000000f3); /* PE_11: D30 (function 3) */
_WDWORD(0x40086730, 0x000000f3); /* PE_12: D31 (function 3) */

_WDWORD(0x40086124, 0x000000f3); /* P2_9: A0 (function 3) */
_WDWORD(0x40086128, 0x000000f3); /* P2_10: A1 (function 3) */
_WDWORD(0x4008612C, 0x000000f3); /* P2_11: A2 (function 3) */
_WDWORD(0x40086130, 0x000000f3); /* P2_12: A3 (function 3) */
_WDWORD(0x40086134, 0x000000f3); /* P2_13: A4 (function 3) */
_WDWORD(0x40086080, 0x000000f2); /* P1_0: A5 (function 2) */
_WDWORD(0x40086084, 0x000000f2); /* P1_1: A6 (function 2) */
_WDWORD(0x40086088, 0x000000f2); /* P1_2: A7 (function 2) */
_WDWORD(0x40086120, 0x000000f3); /* P2_8: A8 (function 3) */
_WDWORD(0x4008611C, 0x000000f3); /* P2_7: A9 (function 3) */
_WDWORD(0x40086118, 0x000000f2); /* P2_6: A10 (function 2) */
_WDWORD(0x40086108, 0x000000f2); /* P2_2: A11 (function 2) */
_WDWORD(0x40086104, 0x000000f2); /* P2_1: A12 (function 2) */
_WDWORD(0x40086100, 0x000000f2); /* P2_0: A13 (function 2) */
_WDWORD(0x40086320, 0x000000f1); /* P6_8: A14 (function 1) */
_WDWORD(0x4008631C, 0x000000f1); /* P6_7: A15 (function 1) */
_WDWORD(0x400866C0, 0x000000f2); /* PD_16: A16 (function 2) */
_WDWORD(0x400866BC, 0x000000f2); /* PD_15: A17 (function 2) */
_WDWORD(0x40086700, 0x000000f3); /* PE_0: A18 (function 3) */
_WDWORD(0x40086704, 0x000000f3); /* PE_1: A19 (function 3) */
_WDWORD(0x40086708, 0x000000f3); /* PE_2: A20 (function 3) */
_WDWORD(0x4008670C, 0x000000f3); /* PE_3: A21 (function 3) */
_WDWORD(0x40086710, 0x000000f3); /* PE_4: A22 (function 3) */

_WDWORD(0x40086094, 0x000000f3); /* P1_5: CS0 (function 3) */
_WDWORD(0x400866B0, 0x000000f2); /* PD_12: CS2 (function 2) */
_WDWORD(0x40086098, 0x000000f3); /* P1_6: WE (function 3) */
_WDWORD(0x4008608C, 0x000000f3); /* P1_3: OE (function 3) */
_WDWORD(0x40086090, 0x000000f3); /* P1_4: BLS0 (function 3) */
_WDWORD(0x40086318, 0x000000f1); /* P6_6: BLS1 (function 1) */

_WDWORD(0x40086324, 0x000000f3); /* P6_9: DYCS0, function 3 */
_WDWORD(0x40086310, 0x000000f3); /* P6_4: CAS, function 3 */
_WDWORD(0x40086314, 0x000000f3); /* P6_5: RAS, function 3 */
_WDWORD(0x4008632C, 0x000000f3); /* P6_11: CKEOUT0, function 3 */
_WDWORD(0x40086330, 0x000000f3); /* P6_12: DQMOUT0, function 3 */
_WDWORD(0x40086328, 0x000000f3); /* P6_10: DQMOUT1, function 3 */

   /* initialise the EMC */
_WDWORD(0x40005000, 0x00000001);      /* Enable */
_WDWORD(0x40005200, 0x00000081);      /* CS0: 16 bit, WE */
_WDWORD(0x40005208, 0x00000001);      /* CS0: WAITOEN = 1 */
_WDWORD(0x4000520C, 0x00000006);      /* CS0: WAITRD = 6 */

_WDWORD(0x40005240, 0x00000081);      /* CS2: 16 bit, WE */
_WDWORD(0x40005248, 0x00000001);      /* CS2: WAITOEN = 1 */
_WDWORD(0x4000524C, 0x00000006);      /* CS2: WAITRD = 6 */
}

FUNC void BootpSetup (void) {
   _wdword(0x40086124,0x40);
   _wdword(0x40086120,0x44);
   _wdword(0x40086088,0x40);
   _wdword(0x40086084,0x40);
   _wdword(0x400f6000,_rdword(0x400f6000) &~ 0x00000300);
   _wdword(0x400f6004,_rdword(0x400f6004) &~ 0x00000400);
   _wdword(0x400f6014,_rdword(0x400f6014) &~ 0x00000080);
}

FUNC void TestBP (void ) {
   _rdword(0x400f5020);
   _rdword(0x400f5024);
   _rdword(0x400f50A8);
   _rdword(0x400f529C);

}

_sleep_(100);
\\M0();
LOAD .\AGR2_M0.axf INCREMENTAL

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:36 GMT

Content originally posted in LPCWare by JohnR on Sat Apr 28 05:21:35 MST 2012
Hi Phil,

"I'm getting slightly confused now what you are trying to do." - not nearly as much as I am, although what you have sent me so far has been immensely useful.

Right now my target is to get both M0 and M4 working simultaneously on stored programs , initially without communications between them, just flashing LEDS or driving the logic analyser, using Red Suite or LPCXpresso. So far, I have had working M4 in flash, M0 in RAM, but not simultaneously. Then tackle inter-processor communications.

It would be great if NXP, Code Red or one of the LPC4300 board manufacturers could put together a seminar series on designing with these dual-core devices.

Thanks yet again,

John.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:37 GMT

Content originally posted in LPCWare by PhilYoung on Mon Apr 30 00:02:45 MST 2012
Hi John,
Perhaps the easiest solution is to make a single image containing both M4 and M0 code and flash it all together.
I wrote my own programmer as the flash on my board is different so I can't guarantee that the programmer supplied is OK.

for this mode first I create the M0 program, then run the following user command.
fromelf --cadcombined --output="..\M4\M0_image\LR0.h" ".\AGR2_M0.axf"
This creates a hex file containing the M0 image.

next I build the M4 code including a source file with the following code, this just changes the type of the hex file so it doesn't get relocated at startup.

extern const
#include "LR0.h"

then I put the followingg in the M4 linker script

LR_M0_IMAGE 0x1C040000 0x00020000 {    ; load region size_region
   ER_M0 0x1c040000 { ; root section for startup code and vector table
      cm0_image.o(+RO +RW +ZI)
.ANY(LR0)
   }
}

Then in the M4 code I conlude the following code to start the M0
/* take SLAVE processor out of reset */
void StartM0(void)
{
volatile uint32_t u32REG, u32Val;

// Release Slave from reset, first read status
u32REG = LPC_RGU->RESET_ACTIVE_STATUS1;

// If the M0 is being held in reset, release it...
// 1 = no reset, 0 = reset
while(!(u32REG & (1u << 24)))
{
u32Val = (~(u32REG) & (~(1 << 24)));
LPC_RGU->RESET_CTRL1 = u32Val;
u32REG = LPC_RGU->RESET_ACTIVE_STATUS1;
};
}

/* put the SLAVE processor back in reset */
void HaltM0(void) {

volatile uint32_t u32REG, u32Val;

// Check if M0 is reset by reading status
u32REG = LPC_RGU->RESET_ACTIVE_STATUS1;

// If the M0 has reset not asserted, halt it...
// in u32REG, status register, 1 = no reset
while ((u32REG & (1u << 24)))
{
u32Val = ( (~u32REG) | (1 << 24));
LPC_RGU->RESET_CTRL1 = u32Val;
u32REG = LPC_RGU->RESET_ACTIVE_STATUS1;
}
}

first do    LPC_CREG->M0APPMEMMAP = (uint32_t)&LR0;
this sets the shadow address for the M0

then just call StartM0() to get the M0 running.
Both the M0 and M4 start executing code from flash, but both images perform the required relocation of their executable code to RAM independently of each other.

regards

Phil.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:37 GMT

Content originally posted in LPCWare by nxp21346 on Mon Apr 30 08:40:12 MST 2012
This definitely sounds like the best idea to me. There are two cores, but it usually makes more sense to merge the images together and download or program them at the same time. We often do this by converting the M0 image into a .c file (binary array) and compiling it into the M4 project.

-NXP

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:38 GMT

Content originally posted in LPCWare by PhilYoung on Wed May 02 04:08:36 MST 2012
Since I just got a new board and experienced a similar problem this might also apply to you.
The flash programmer was not setting up ALL of the address pins on the EMC, which was not a problem initially, but on the new board there are additional address pins which if not configured by default are pulled high.

Flash programming succeeds, but the actual data is written to the wrong flash location, however it's also read back from that location and flash verfies ok.

When the program starts it configures ALL address lines, but as soon as it configures an address line that was not configured in the programmer that line goes low and the program crashes, of course in by case the image I assumed was at 0x1c000000 was really at 0x1c400000.

so check the programmer to ensure that ALL address bits are configured.

The boot loader will set these low when booting from flash, but if you use the debugger to start the code then you MUST set them to the correct mode with a script.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:39 GMT

Content originally posted in LPCWare by JohnR on Sat May 05 15:34:19 MST 2012
Hi Phil and others,

With a lot of support and code from CodeRed I now have succeeded in running a simple project on my Diolan board that uses both M4 and M0. At the present M4 simply toggles a port that feeds a logic analyser and sends a message to M0 to toggle another port. Simple but it took a while to get there.

Getting Code Red's Red Suite 4 compiler and their Red Probe+ also helped a lot. LPC_Link and LPCXpresso worked but downloading was slow as the system looks first for Red Probe and only after a while accepts LPC_Link.

JohnR.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:40 GMT

Content originally posted in LPCWare by sjalloq on Sat Jun 02 12:31:05 MST 2012
A loaded question for you - when and where are you going to put up the details of this example so others can follow?

Hopefully I haven't just missed it on the forum. :-)

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:40 GMT

Content originally posted in LPCWare by JohnR on Sun Jun 03 05:16:57 MST 2012
Hi,

CodeRed have just released an example of using both M4 and M0.

http://support.code-red-tech.com/CodeRedWiki/LPC43DualCoreProjects.

They were exceptionally patient in helping me get going.

The example they sent me was for the Hitex board so I modified it to work with the Diolan board, mixing in some of the Diolan example code, using their message passing scheme to turn on/off one of the LEDs using one of the buttons.

If you would still like the code, I will check with CodeRed to see if they mind, though I don't see why they would.

John.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:41 GMT

Content originally posted in LPCWare by sjalloq on Sun Jun 03 06:22:35 MST 2012
Hi John,

thanks, that would be really useful if you could either post the code or detail the modifications needed. I have already seen their example but it doesn't work out of the box on the Diolan board so I started looking at the flash code...

...which has opened another can of worms. Code Red state on their website that they have customers using the SST39VF3201B flash driver bundled with the IDE but this can't be correct as the Spansion and Microchip parts have different commands. Did you find that you had to modify the flash driver? I'm just going through that now.

Thanks, Shareef.

Re: Flash frustrations

lpcware — Wed, 15 Jun 2016 19:12:41 GMT

Content originally posted in LPCWare by JohnR on Sun Jun 03 10:45:17 MST 2012
Hi Shareef,

I will write today to CodeRed about posting the M4/M0 project.

At the moment I use the RedSuite compiler and Red Probe for downloading. Earlier I used LPCXpresso and the LPC_Link module for downloading code. I had a lot of problems at that time trying to get the Diolan dual M4/M0 examples working on LPCXpresso but with CodeRed's help all is well mow.

I assume you mean Micron not Microchip. I haven't checked the Spansion datasheet but the Micron device seems to behave properly on the Diolan board.

JOhn.