2018-02-23 01:14 AM
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?
2018-02-23 03:04 AM
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
2018-02-23 02:42 PM
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.
2018-02-26 05:37 AM
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
2018-02-26 12:41 PM
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 theSPC56ELxx_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. ***
2018-02-26 11:27 PM
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
2018-02-27 03:49 AM
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
2018-02-27 04:37 PM
So the second core (Core1) cannot run a PIT handler function like Core0 can?
2018-02-28 01:25 AM
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
2018-02-28 10:23 PM
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>