LPC4357 Dual-Core programming error

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Mon Jun 17 06:09:26 MST 2013
When programming the LPC4357 using a Red Probe+ and LPCXpresso 5.2.4 I get an exit error when programming the device from the GUI tool. The command line tool just hangs (at the same point).

First the flash area of the M4 (Flash A) gets programmed successfully, then the flash area of the M0 core (Flash B) gets programmed (also successfully). And then area just after the first Flash A gets programmed (only 76 bytes @ address 0x1A0016DC). But this is the points where the trouble starts.

I get an exit code -1073741819

I use this command:

crt_emu_lpc18_43_nxp -g -2 -vendor=NXP -pLPC4357 -s1000 -flash-load-exec "D:\dual_core_test\M4app\Debug\M4app.axf"

[B]This is the output of the crt_emu_lpc18_43_nxp tool:[/B]

Ni: LPCXpresso Debug Driver v5.2 (Apr 26 2013 19:52:27 - crt_emu_lpc18_43_nxp.exe build 1153)
Pc: (  0) Reading remote configuration
Nc: Looked for chip XML file in C:/nxp/LPCXpresso_5.2.4_2122/lpcxpresso/bin/LPC4357.xml

Nc: Looked for vendor directory XML file in C:/nxp/LPCXpresso_5.2.4_2122/lpcxpresso/bin/nxp_directory.xml

Nc: Found generic directory XML file in C:/nxp/LPCXpresso_5.2.4_2122/lpcxpresso/bin/crt_directory.xml

Pc: (  5) Remote configuration complete
Pc: ( 30) Emulator Connected
Pc: ( 40) Debug Halt
Pc: ( 50) CPU ID
Nc: Emu(0): Conn&Reset. DpID: 2BA01477. Info: FTVD2TSMA
Nc: SWD Frequency: 1000 KHz. RTCK: False. Vector catch: False.
Nc: Packet delay: 0  Poll delay: 0.
Nc: Loaded LPC18x7_43x7_2x512_BootA.cfx: LPC18x7/LPC43x7 Flash 2x512KB @0x1A000000 (Boot Bank A) Aug 17 2012 00:15:43  On-chip Flash Memory

Nc: NXP: LPC4357  Part ID: 0x00000000
Pc: ( 65) Chip Setup Complete
Nt: Connected: was_reset=false. was_stopped=false
Cr:v Registered license, download limit of 128K
Pc: ( 70) License Check Complete
Nt: Loading ELF file 'M4app.axf' at location 1A000000
Nt: Writing 5852 bytes to 1A000000 in Flash (assumed clock: 72.0MHz)
Pb: 1 of 1 (  0) Writing pages 0-0 at 0x1A000000 with 5852 bytes
Ps: (  0) Page  0 at 1A000000
Ps: (  0) Page  0 at 1A000000: 4096 bytes
Ps: ( 69) Page  0 at 1A001000: 1756 bytes
Nt: Erased/Wrote page  0-0 with 5852 bytes in 780msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash write Done
Nt: Loading ELF file 'M4app.axf' at location 1B000000
Nt: Writing 716 bytes to 1B000000 in Flash (assumed clock: 72.0MHz)
Pb: 1 of 1 (  0) Writing pages 15-15 at 0x1B000000 with 716 bytes
Ps: (  0) Page 15 at 1B000000
Ps: (  0) Page 15 at 1B000000: 716 bytes
Nt: Erased/Wrote page  15-15 with 716 bytes in 289msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash write Done
Nt: Loading ELF file 'M4app.axf' at location 1A0016DC
Nt: Writing 76 bytes to 1A0016DC in Flash (assumed clock: 72.0MHz)
Pb: 1 of 1 (  0) Writing pages 0-0 at 0x1A0016DC with 76 bytes
Ps: (  0) Page  0 at 1A0016DC

[B]From the memory map I read that the data at that point in flash has something to do with:
[/B]

*(.isr_vector)
 .isr_vector    0x1a000000      0x114 ./src/cr_startup_lpc43xx.o
                0x1a000000                g_pfnVectors
                0x1a000114                . = ALIGN (0x4)
                0x1a000114                __section_table_start = .
                0x1a000114                __data_section_table = .
                0x1a000114        0x4 LONG 0x1a0016dc LOADADDR (.data)
                0x1a000118        0x4 LONG 0x10000000 ADDR (.data)
                0x1a00011c        0x4 LONG 0x4c SIZEOF (.data)
                0x1a000120        0x4 LONG 0x1a0016dc LOADADDR (.data_RAM2)
                0x1a000124        0x4 LONG 0x10080000 ADDR (.data_RAM2)
                0x1a000128        0x4 LONG 0x0 SIZEOF (.data_RAM2)
                0x1a00012c        0x4 LONG 0x1a0016dc LOADADDR (.data_RAM3)
                0x1a000130        0x4 LONG 0x20000000 ADDR (.data_RAM3)
                0x1a000134        0x4 LONG 0x0 SIZEOF (.data_RAM3)
                0x1a000138        0x4 LONG 0x1a0016dc LOADADDR (.data_RAM4)
                0x1a00013c        0x4 LONG 0x20008000 ADDR (.data_RAM4)
                0x1a000140        0x4 LONG 0x0 SIZEOF (.data_RAM4)
                0x1a000144        0x4 LONG 0x1a0016dc LOADADDR (.data_RAM5)
                0x1a000148        0x4 LONG 0x2000c000 ADDR (.data_RAM5)

[B]
And
[/B]

.rodata.CGU_PERIPHERAL_Info
                0x1a001554      0x188 D:\dual_core_test\CMSIS_LPC43xx_DriverLib\Debug\libCMSIS_LPC43xx_DriverLib.a(lpc43xx_cgu.o)
                0x1a001554                CGU_PERIPHERAL_Info
                0x1a0016dc                . = ALIGN (0x4)

.glue_7         0x1a0016dc        0x0
 .glue_7        0x00000000        0x0 linker stubs

.glue_7t        0x1a0016dc        0x0
 .glue_7t       0x00000000        0x0 linker stubs

.vfp11_veneer   0x1a0016dc        0x0
 .vfp11_veneer  0x00000000        0x0 linker stubs

.v4_bx          0x1a0016dc        0x0
 .v4_bx         0x00000000        0x0 linker stubs

.ARM.extab
 *(.ARM.extab* .gnu.linkonce.armextab.*)
                0x1a0016dc                __exidx_start = .

.ARM.exidx
 *(.ARM.exidx* .gnu.linkonce.armexidx.*)
                0x1a0016dc                __exidx_end = .
                0x1a0016dc                _etext = .

.data_RAM2      0x10080000        0x0 load address 0x1a0016dc
 FILL mask 0xff
 *(.data.$RAM2*)
 *(.data.$RamLoc40*)
                0x10080000                . = ALIGN (0x4)

.data_RAM3      0x20000000        0x0 load address 0x1a0016dc
 FILL mask 0xff
 *(.data.$RAM3*)
 *(.data.$RamAHB32*)
                0x20000000                . = ALIGN (0x4)

.data_RAM4      0x20008000        0x0 load address 0x1a0016dc
 FILL mask 0xff
 *(.data.$RAM4*)
 *(.data.$RamAHB16*)
                0x20008000                . = ALIGN (0x4)

.data_RAM5      0x2000c000        0x0 load address 0x1a0016dc
 FILL mask 0xff
 *(.data.$RAM5*)
 *(.data.$RamAHB_ETB16*)
                0x2000c000                . = ALIGN (0x4)

.uninit_RESERVED
                0x10000000        0x0
 *(.bss.$RESERVED*)
                0x10000000                . = ALIGN (0x4)
                0x10000000                _end_uninit_RESERVED = .

.data           0x10000000       0x4c load address 0x1a0016dc
 FILL mask 0xff
                0x10000000                _data = .

What is going wrong here?
Strangely enough everything goes well when entering a debug session on the M4. Both Flash A and B get programmed, but the last area (where the errors are) is ignored. After a manual reset the program works fine, even without debugger.

BTW, version 5.2.2 of LPCXpresso shows no error programming, however the code itself does not run properly. Only when I first invoke a debug session (which includes automatic programming/flashing) the code runs properly afterwards (e.g. after reset/no debugging active). This is this case for both 5.2.2 and 5.2.4. Anybody from Code Red knows the cause maybe? What are the differences in programming/flashing between the debug session and the GUI tool.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Tue Jul 30 11:51:38 MST 2013

Quote: drs

Also be aware that there is a new errata concerning problems with divide by two mode on the external memory controller: http://www.nxp.com/documents/errata_sheet/ES_LPC435X_3X_2X_1X_FLASH.pdf

Thanks for pointing that out. This explains the strange behaviour I have seen during SDRAM access. The only situation for which this is relevant is when the cpu(s) run at 204 MHz and consequently the EMC at 102 MHz. Unfortunatly that is where I was.

Running them at 156 MHz seems to work well despite the 120 MHz statement.

I think it is best to go to 192/96 MHz for now.

BTW still have to test the flash driver.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by drs on Tue Jul 30 11:02:04 MST 2013
The external memory controller on the LPC4357 cannot be run over 120MHz. See Tcy(clk) in the data sheet.

Also be aware that there is a new errata concerning problems with divide by two mode on the external memory controller: http://www.nxp.com/documents/errata_sheet/ES_LPC435X_3X_2X_1X_FLASH.pdf

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Mon Jul 29 02:48:42 MST 2013

Quote: wlamers
[One thing I noticed is that the flash tool flashes in blocks of 4096 bytes and via GDB 32768 at a time.

I'm not sure what you are looking at here, but you are basically using the same flash driver under both the debugger and the GUI flash tool. Thus these will both program in 4KB blocks.

If booting into ISP mode before programming flash more reliable (either via the GUI flash programming tool or via the debugger), this would indicate that something in the way you are setting the clock up in your code base is preventing the flash driver functioning correctly.

I've attached a new version of the flash driver file which has a subtle change in its initialisation sequence which might work around this clock issue. Please can you unzip this and drop the .cfx into the /bin/Flash subdirectory of your lpcxpresso installation and let us know if you see any change in behaviour. You might want to back up the original first.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Fri Jul 26 00:12:19 MST 2013

Quote: lpcxpresso-support
In what way is it not going well? Can you provide details, including the log from a programming failure? Did resetting your board into ISP mode before attempting to program the flash, as I suggested previously, make any difference?

Using LPCXpresso 5.2.6 does no give any error using the flash tool. See also earlier post. Using 5.2.4 causes the tool to hang wrting the last block. But if I understand correcty this had something to do with the call to the tool inside Eclipse and has been fixed. Version 5.2.6 does flash completely but the firmware does not run properly. Flashing after ISP is invoked on the board seems to work better (not 100% sure yet). For the mean time I rely on flashing with the debugger. One thing I noticed is that the flash tool flashes in blocks of 4096 bytes and via GDB 32768 at a time.

Quote: lpcxpresso-support
These debug configuration options do not apply to these parts (which I'll flag as needing to be made more obvious in a future release). The flash driver will simply reset the clock to use the IRC.

Ah that explains why there is no difference in setting these values or not. Thanks.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Jul 24 09:19:09 MST 2013

Quote: wlamers
Unfortunately this cost me some performance, but the programming of the flash seems to work OK when invoking a debug session. Still programming using the flash tool is not going well. But I can live with that.

In what way is it not going well? Can you provide details, including the log from a programming failure? Did resetting your board into ISP mode before attempting to program the flash, as I suggested previously, make any difference?

Quote: wlamers

Regarding the debug configuration: I have set the XTAL and PLL values to '12000, 72000' in the Target Configuration settings.

These debug configuration options do not apply to these parts (which I'll flag as needing to be made more obvious in a future release). The flash driver will simply reset the clock to use the IRC.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Wed Jul 24 00:32:02 MST 2013
I think I have found some sort of solution, or at least an improvement. I have changed the SDRAM clock divider from 2 to 1, e.g. now it runs in sync with the M4 core. And I have lowered the main clock from 204 MHz to 156 Mhz. This was necessary since the SDRAM can only run up to 160 MHz. Unfortunately this cost me some performance, but the programming of the flash seems to work OK when invoking a debug session. Still programming using the flash tool is not going well. But I can live with that.

Regarding the debug configuration: I have set the XTAL and PLL values to '12000, 72000' in the Target Configuration settings. The 12000 corresponds well with the crystal I use (although not connected to the crystal inputs but to the GPCLKIN pin). But the PLL value is way off (it should be 156000 obviously). Strangely enough I get an error saying that the PLL value in incorrect. Why can’t I set the correct PLL value? I seems although that debugging works ok.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Thu Jul 18 03:35:03 MST 2013
So if you boot into ISP mode before attempting to program, does that help?

Or if you set the vector catch option in your launch configuration, does that help?

And if you try changing the clock setup to "something more simple", does that help?

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Thu Jul 18 02:06:03 MST 2013
Hello lpcxpresso-support,

Thanks for the test.

I guess you get that error since my board is using an external clock buffer which is routed to the GP_CLKIN pin instead of the crystal input. Changing the clock source of the core from the interal resonator to the clock input pin causes the debugger to lose connection I guess (there is no clock anymore after all in case of the Keil board, which uses a crystal).

My apologizes, I forgot to mention this. Did not realize it at the time of posting...

BTW this is the SystemSetupClocking function:

STATIC void SystemSetupClocking(void)
{
int i;

Chip_SCU_PinMuxSet(0xF, 4, (SCU_MODE_MODE_PULLDOWN | SCU_MODE_INBUFF_EN | SCU_MODE_ZIF_DIS | SCU_MODE_FUNC1));

/* Setup FLASH acceleration to target clock rate prior to clock switch */
Chip_CREG_SetFlashAcceleration(MAX_CLOCK_FREQ);

/* Switch main system clocking to external pin */
Chip_Clock_DisableCrystal();
Chip_Clock_SetBaseClock(CLK_BASE_MX, CLKIN_CLKIN, true, false);


/* Setup PLL for 108MHz and switch main system clocking */
Chip_Clock_SetupMainPLLHz(CLKIN_CLKIN, CRYSTAL_MAIN_FREQ_IN, 108 * 1000000, 108 * 1000000);
Chip_Clock_SetBaseClock(CLK_BASE_MX, CLKIN_MAINPLL, true, false);
emc_WaitMS(10);

/* Setup PLL for maximum clock, 204 MHz */
Chip_Clock_SetupMainPLLHz(CLKIN_CLKIN, CRYSTAL_MAIN_FREQ_IN, MAX_CLOCK_FREQ, MAX_CLOCK_FREQ);
emc_WaitMS(10);

/* Setup system base clocks and initial states. This won't enable and disable individual clocks, but sets up the base clock sources for each individual peripheral clock. */
for (i = 0; i < (sizeof(InitClkStates) / sizeof(InitClkStates[0])); i++) {
Chip_Clock_SetBaseClock(InitClkStates.clk, InitClkStates.clkin,
InitClkStates.autoblock_enab, InitClkStates.powerdn);
}


/* Setup USB0 PLL state for a 480MHz output and attach */
LPC_CGU->PLL[0].PLL_CTRL |= 1; // Power down PLL
LPC_CGU->PLL[0].PLL_NP_DIV = (98<<0) | (514<<12);
LPC_CGU->PLL[0].PLL_MDIV = (0xB<<17)|(0x10<<22)|(0<<28)|(0x7FFA<<0);
LPC_CGU->PLL[0].PLL_CTRL = (CLKIN_CLKIN<<24) | (0x3<<2) | (1<<4);
Chip_Clock_SetBaseClock(CLK_BASE_USB0, CLKIN_CLKIN, true, false);


/* Setup CLKOUT */
Chip_Clock_SetDivider(CLK_IDIV_E, CLKIN_MAINPLL, 10); // Divider E = 10
Chip_Clock_SetBaseClock(CLK_BASE_OUT, CLKIN_IDIVE, true, false);
}

Strange thing about these problems is that it is only happening once in a while.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Thu Jul 18 01:43:26 MST 2013
I've tested out the programming of your application to a Keil MCB4357 board here. The board works fine using a set of other test images, until I program in your image. After starting a debug session with your image, I start getting connection errors and the only way to recover the board so that I can program a different image in is to boot the board into ISP mode:

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

By booting in ISP mode, then setting a breakpoint at the start of ResetISR in your image (by changing the initial breakpoint in the launch configuration from 'main' to the address of ResetISR ('*0x1a002eb8'), I can successfully program your image and then start to step through its initialisation sequence.

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

Tracing this through, I can see that the debug connection is lost when the call chain reaches:

ResetISR -> SystemInit -> SystemSetupClocking -> Chip_Clock_SetBaseClock

Thus it looks like something in your clock setup code is killing the debug connection.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Wed Jul 17 06:40:46 MST 2013
This is the debug log:

LPCXpresso Debug Driver v5.2 (Jul  5 2013 11:31:29 - crt_emu_lpc18_43_nxp build 15)
Found chip XML file in D:/Venamics/Producten/VMS-20/FIRMWARE2/VMS20_Master_M4/Debug/LPC4357.xml
Emu(0): Conn&Reset. DpID: 4BA00477. Info: FTVD2TSMA
JTAG Frequency: 3000 KHz. RTCK: False. Vector catch: False.
Packet delay: 8  Poll delay: 8.
Loaded LPC18x7_43x7_2x512_BootA.cfx: LPC18x7/LPC43x7 Flash 2x512KB @0x1A000000 (Boot Bank A) Aug 17 2012 00:15:43  On-chip Flash Memory
NXP: LPC4357  Part ID: 0x00000000
Connected: was_reset=false. was_stopped=false
v Registered license, download limit of 128K
Writing 87672 bytes to 1A000000 in Flash (assumed clock: unknown)
Flash driver "ProgramPage" return code: 0x1
15: Target error from Write Flash: Ef(38). Flash operation has returned an error (see log).
Stopped: VectorCatch:HardF (PC was 0x1A00A592) (VectorCatch)

The LPCXpresso version is 5.2.6, LPCOpen 1.03, NXPUSBLib supplied from LPCOpen 1.03. Dual core configuration according to Code Red tech guidelines (e.g. not from LPCopen examples).

AXF and MAP is supplied in the zip.

Thanks.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Jul 17 05:16:00 MST 2013
IIRC the problem that you reported before was simply an issue with the way the IDE was invoking the GUI flash programmer for these parts.

To look into your current programming issue, please can you post the debug log:

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

and assuming that you aren't in a position to post an example application with which you see the issue...

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

...can you please also ZIP up and attach the map file and AXF from your application. Can you also confirm which version of LPCOpen / NXPUSBLib you are using?

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Wed Jul 17 01:30:59 MST 2013
Hmm I have to come back one the previous post it seems... Flashing the MCU with the flash tool is still not working correctly with v5.2.6. Also flashing using debugging is becoming a problem too. I get the following error in, let's say, 20-40% of the debug sessions:

Flash driver ProgramPage return code: 0x1

It is a dual core application (bankA for the M4 and bankB for the M0). I also use USB functionality (NXPUSBLib from LPCOpen). I get the feeling that the dual core nature and the USB code have to do something with these errors.

@Code Red Support: do have already have located the problems from the earlier .axf file?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Thu Jul 11 01:23:15 MST 2013
Version 5.2.6 of LPCXpresso seems to be working well with this!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed Jun 19 03:58:42 MST 2013
At present, as you have already noted, using the Debug button will correctly program the flash. Thus whilst we investigate you will need to use this method of programming flash rather than the GUI flash programmer.

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Wed Jun 19 02:52:56 MST 2013

Quote: CodeRedSupport
If you'd like to attach your .axf file we'll look into the behavior.

Regards,

CodeRedSupport

Hello CodeRedSupport,

I have made a new LPC4357 board design and tested the dual core programming behaviour on this new board also. Unfortunately the result is the same. Therefore I think the problem is not related with the hardware. Strangely enough the programming goes well when initiating a debug session on the M4. After a hardware reset the program is running fine (also during deguggint by the way). Why would 'normal flashing' be different from the flashing performed prior to debugging?

I have a lot a dual-core coding to do, so I really need the direct flashing option.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Tue Jun 18 00:28:19 MST 2013
I realized I have posted the .axf file of LPCXpresso 5.2.2. This post contains both versions (M4app_5.2.2 and M4app_5.2.4) as well as the dual-core MCB4357_blinky example which also has the same flashing/programming error.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Mon Jun 17 22:42:57 MST 2013
Sure, no problem, here you go.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Mon Jun 17 14:58:42 MST 2013
If you'd like to attach your .axf file we'll look into the behavior.

Regards,

CodeRedSupport