Dual Core Example in lpc43xx CMSIS Library

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Dual Core Example in lpc43xx CMSIS Library

648 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jokn on Mon Sep 24 07:16:33 MST 2012
I'm testing the LPC43xx CMSIS library Vers 2012-05-31.
Here the dual core example:
/Examples/DUALCORE/Int_Demo.

The SPIFI Version works fine on my custom board as well as on the hitex board.
Then I tried the to run the M4_RAM target configuration and always get a Hard Fault (Vector Table Fault)
I spend al lot of time to find out the reason for such a strange behavior. Finally inspected the debug initialization file:
LPC43xx Internal SRAM.ini
and found some initializations for the M0 core.
When I comment out the Pre_setuo() statement, the Hard Fault vanished an the project works fine including the IPC communication with the M0 core

Does anybody know what is the real intention of the M0 Pres_Setup() and why it causes a Hard Fault?

FUNC void Pre_Setup (void) {

/* configure M0 for infinite loop */
_WDWORD(0x10080000,0x00001F00);/* dummy stack pointer */
_WDWORD(0x10080004,0x000000D5);/* reset handler */
_WDWORD(0x100800D4,0xE7FEE7FE);/* jump to itself instruction for M0a */
_WDWORD(0x40043404,0x10080000);/* M0 shadow pointer. */

/* release M0 from reset to allow Jtag access */
_WDWORD(0x40053104,(~(_RDWORD(0x40053154))) & (~(1<<24)));

}


FUNC void Setup (unsigned int region) {
  region &= 0xFF000000;
  SP = _RDWORD(region);                          // Setup Stack Pointer
  PC = _RDWORD(region + 4);                          // Setup Program Counter
  _WDWORD(0xE000ED08, region);                   // Setup Vector Table Offset Register
}


/* prepare M0 for access, if needed */
//Pre_setup();

/* uncomment the following line if using a Jlink, and uncheck the "load application at startup" */
/* checkbox inthe project settings > debug window in uVision */
/*
LOAD "keil_output\\LPC43xx Internal SRAM\\example.axf" INCREMENTAL
*/

Setup(0x10000000); // Get ready to execute image in SRAM

Labels (1)
0 Kudos
4 Replies

539 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Tue Oct 02 07:42:00 MST 2012
Hello Josef,

at least the problem with the double reset when executing from SPIFI is a documented problem (errata sheet). The problem is in the ROM bootloader, which does a wrong interpretation of a result from a query.
- In case of a non-initialized qSPI (cold start) the interpretation is fine and the device starts correctly.
- In case of an initialized device (first reset) the interpretation is wrong and the bootloader runs into a timeout loop. After 60s an internal reset is generated and you should see it starting correctly.
- or you apply a second reset

If we do a new chip revision we will of course fix this bug.

The LPC4350 always starts running with the IRC (exception is the USB bootmode), so if your external crystal does not start then you simply didn't reach the point where you enable it in your application code.

And coming back to the Pre_Setup for the M0: if you don't intend to debug the M4 and the M0 at the same time, then simply don't execute Pre_Setup. Then the M0 stays in reset until you release it in you application code.

Best regards,
NXP Technical Support
0 Kudos

539 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jokn on Wed Sep 26 12:37:25 MST 2012
Hello bavarian,

I have found another strange effect regarding the CPU reset input. I flashed the dual core demo in the spi flash on the hitex board and it is running.
Now I try to restart it by pressing the reset button. It’s crazy but indeed I have always to press the button twice, to restart the CPU.
On first press the application stops and no LED is blinking, then on the second press the application begins running.

The same application on my custom board, which is quite equal to the hitex board, I don’t get the application running with the reset button at all. only with power up.
With a scope I can see, that the extern crystal oscillator don’t start running when I press the reset button. Therefore I tried to run without extern oscillator, but with the same effect –
Power up OK reset not. So I assume that the CPU don’t run until the initialization of core clock.

Regards
Josef
0 Kudos

539 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jokn on Wed Sep 26 09:44:14 MST 2012
Hello bavarian,

Thanks for reply. OK I understand now the function of PreSetup.
My first attempt to get it running by changing the Pre_Setup was only haphazard with success.
But when I make a power off / on reset it will work fine for a time. That means for several new connect and disconnects with the Jtag box.
For now I know if after connection something went wrong, I have to make a cold reset.

My debugger settings are connect-Normal and VECTRESET indeed.
I have tried also with Pre-Reset and HW RESET, but HW RESET doesn’t work at all (Error Message “Target has been canceled”)

Best Regards
Josef
0 Kudos

539 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Tue Sep 25 03:41:25 MST 2012
Hello,

the reason for this Pre_Setup is the behavior of the debugger. Neither the µVision debugger nor the boxes like ULINK or JLINK were initially prepared for multicore chips. When you power on the LPC435x the Cortex-M4 handles the bootloader and the M0 is kept in reset. Due to the fact that the new versions of ULINK or JLINK support the dual core setup, you could also debug both cores at the same time with one debugger box.
But before you can start a second instance of the debugger for the Cortex-M0 you must ensure in the first instance for the Cortex-M4 that the M0 is set up properly. You need to provide a minimum of executable code and the start address (first four _WDWORD) before you let the M0 out of reset.
If you would do this without preparation the debugger notices a change on the scan chain configuration and quits gracefully.

Why it causes a hard fault: to be honest, I don't know. I tested it with the example from lpcware, an LPC4350, µVision 4.54 and a ULINK2 (firmware V1.42) and it works fine. Try to play a little bit with the reset strategy in the debugger settings, normally Reset after connect - Normal - VECTRESET works best.

Best regards,
NXP Technical Support
0 Kudos