cancel
Showing results for 
Search instead for 
Did you mean: 

Debugging Dual Core SPC56

Matthew Richardson
Associate II
Posted on February 23, 2018 at 10:14

I have a DPM configuration for SPC56EL70.  I initially had some trouble getting the debugger to connect to the target ( could connect fine in LSM.)  The problem had to do with not clearing the LSM_DPMB bit.  Erwan found this FAQ which left me some really good bread crumbs:  

https://www.pls-mc.com/microcontroller-faqs/faqs-a-1291.html?sh8=bHNt

 

Using PLS-UDE v4.8:

1) Connect to the target using a known working LSM mode configuration.

2) Open the FLASH/OTP Memory Programming Tool

3) Select 'SHADOW FLASH' from Memory Device dropdown and check 'Enable' to make the connection, then Exit.

4) Open a Memory Window and navigate to BIU4 address, which is 0x00FF_FE10

5) Change the Address value to FFBF_FFFF, and the field will be red indicating that it doesn't match.

6) Open the FLASH/OTP Memory Programming Tool again and notice that the Program All button is enabled, then program and verify.

7) Power off the processor and restart.  Reconnect using a DPM configuration/workspace and you should be able to connect to the target.  There should be both Core0 and Core1 binaries/symbols when Load Program is selected from the File Menu.

I followed those steps with some success of being able to connect and dataload.  I don't know if what I did is correct (even if it does connect) as I read the reference manual, bit 0x0040_0000 is not the LSM_DPMB bit as described in User Options Table.  Bit 9, not bit 22 should toggle

LSM_DPMB.

 Maybe the BIU4 address doesn't map the same as the User Option Bits?  I don't know.  It seems esoteric.

The problem:

The problem I am having is that when I debug, the program gets stuck in SPCSetRunMode() waiting for ME.IS.R != 0U.  If I disconnect from the target and reset, then the program runs while not debugging.  However, my main_core1()  routine is never started.  My guess is that I'm either not configured correctly to debug, or that there is a PLS - .wsx alignment issue.  Does anyone have a wsx and a small DPM helloworld out there?

This discussion has been locked for participation. If you have a question, please start a new topic in order to ask your question
10 REPLIES 10
Erwan YVIN
ST Employee
Posted on February 23, 2018 at 12:04

Hello Matthew ,

Did you check SPC56ELxx_RLA DualCore Test Application for DiscoveryPlus from SPC5Studio ?

it is nice HelloWorld for this device.

I am checking your point 

'

I don't know if what I did is correct (even if it does connect) as I read the reference manual, bit 0x0040_0000 is not the LSM_DPMB bit as described in User Options Table.  Bit 9, not bit 22 should toggle

LSM_DPMB.

 Maybe the BIU4 address doesn't map the same as the User Option Bits?  I don't know.  It seems esoteric.'

Could you give me your Revision version of the RM ?

         Best regards

                         Erwan

Posted on February 23, 2018 at 22:42

The PLS instructions from the FAQ were not very good, so like you I am hoping to contribute as much as I can on lessons learned.  The reference manual I have is RM0032 Rev 13,  see Table Table 307.

For SPC56ELxx_RLA DualCore, many thanks.

Posted on February 26, 2018 at 13:37

Hi Matthew, 

let me confirm that your procedure to enable the DPM mode is correct. The bit to be set to 0 is the bit 9, so the value to program is correctly 0x

FFBFFFFF (the bit position is inverted bit0 ... bit31). 

After to enable the DPM, I have just verified on my 

Leopard DiscoveryPlus board with SPC56EL70L5 that the test application suggested by Erwan (SPC56ELxx_RLA DualCore Test Application for DiscoveryPlus) works fine. Please, let me underline that to download and execute a dual core test application, it is necessary to use a special cfg file for the UDE debug that is set as default in the SPC56ELxx_RLA DualCore Test Application for DiscoveryPlus.

Best regards,

Luigi

Posted on February 26, 2018 at 20:41

Thanks Luigi, I have also had a lot of success in the dual core operation.  The instructions I provided work, even though I fully do not understand why that particular bit is 

LSM_DPMB.  My guess is that the BIU4 register doesn't directly map over the the User Option Bits.  

 I had to update SPC5Studio to find the

SPC56ELxx_RLA DualCore Test Application.  Also, as you said, the debug.wsx provided in that example application worked without any issues.  ***Very good work getting that posted ST.  ***

Matthew Richardson
Associate II
Posted on February 27, 2018 at 08:27

I don't want to keep this thread going.  I am using multiple cores to decide up custom uart functions (bit-banging).  I need a PIT to run on each core.  I notice that only a core0 [only] is implemented on all of the low level drivers.  I would imagine that for dual core to be fully implemented, that a core option would need to be provided in the configuration scheme.  I've been implementing some, but it obviously gets written over when I generate.  Other than initializing  main_core1(), dual core support of the lld'sdoesn't seem to be implemented.  Is this a future implementation plan?

Cheers, 

~Matt

Posted on February 27, 2018 at 11:49

Hi Matthew,

with the current low level drivers version you can manage all the peripherals from both cores. Please, note that the peripherals are shared between the 2 cores, and not duplicated. Moreover, please, take into account that the peripheral interrupts are managed only by the core 0 (Main Core). 

Regards,

Luigi

Posted on February 28, 2018 at 00:37

So the second core (Core1) cannot run a PIT handler function like Core0 can?

zambrano.luigi
Senior III
Posted on February 28, 2018 at 10:25

Hi Matthew,

let me clarify my previous feedback about the interrupt. When I say that the peripheral interrupts are managed only by core 0, I meant that this is the current implementation in SPC5Studio. As explained in the Leopard Reference Manual (section Interrupt sources), the interrupts generate by the off-platform peripherals (e.g. PIT) are routed to both interrupt controllers (INTC_0 related to core 0 and INTC_1 related to core 1). In particular, in Decoupled Parallel Mode the interrupt load can be distributed to both cores by assigning different interrupt levels (interrupt level 0 to effectively disable an IRQ) to the same source at each interrupt controller. Currently there is no plan to develop this support in SPC5Studio.

Regards,

Luigi

Matthew Richardson
Associate II
Posted on March 01, 2018 at 07:23

I feel like I am close.  Setting the channel 2 PIT priority to 0 in INTC_0 does prevent core0 from triggering an interrupt.  However, setting a priority for INTC_1 hasn't worked for me yet; core1 never runs the PIT CH2 handler.  I am guessing that somewhere in the initialization, whether components or in timers, I don't fully have the interrupter for INTC_1 enabled.

<c>

#define INTC_1_BASE 0x8FF48000U

#define INTC_1_PSR(n) (*((volatile uint8_t *)(INTC_1_BASE + 0x40U + ((uint16_t)(n) * sizeof (uint8_t)))))

int main(void)

{

  runCore1();

  osalThreadDelaySeconds(2);

  // initialize components

  componentsInit();

  irqIsrEnable();

  //Disable the PIT2 channel for INTC_0 by setting priority to zero (This works, prevents core0 from running CH2)

  INTC_PSR(SPC_PIT_CH2_INT_NUMBER) = INTC_PSR_ENABLE(0x00, 0x00);

  //Set the PIT2 channel for INTC_1 by setting priority to the configured setting

  //(This does not work, cannot get t_80_PIT handler to be called)

  INTC_1_PSR(SPC_PIT_CH2_INT_NUMBER) = INTC_PSR_ENABLE(0xC0, 0x04);   

//^^^  Note: I found in another reference manual that 0xC0 is for choosing the core, but I think these are ignored (shot in dark)

  pit_lld_start(&PITD, pit_config);

  pit_lld_channel_start(&PITD, 1U);

  pit_lld_channel_start(&PITD, 2U);

  // main loop

  for ( ; ; ) { }

}

int main_core1(void)

{

  osalThreadDelaySeconds(2);

  irqIsrEnable();

  // main loop

  for ( ; ; ) { }

  return 0;

}

// t_200_PIT is a 200kHz periodic timer called by Periodic Interrupt Timer channel 1

void t_200_PIT(void)

{

  pal_lld_togglepad(PORT_D, LED_RED);

}

// t_190_PIT is a 190kHz periodic timer called by Periodic Interrupt Timer channel 2

void t_190_PIT(void)

{

  pal_lld_togglepad(PORT_D, LED_GREEN);

}

</c>