Changin processor package in a multicore project results in unwanted changes in flash and RAM

[pmrlcbtcphtzjdq]

After changing the processor in a multicore project, the memory organization in linker files resets each core to the default single-core memory mapping.

I'm trying to design a multicore application with MPC5748G. Unfortunately, I can't flash any project on to the second core (more in this thread ), so I tried designing a multicore application with the S32 wizard ('New'->'S32DS Application Project'->'MPC5748G'->3 core project), and work from that. However, by default, it initializes the wrong PinPackage of the Processor. I am using MPC5748G devkit with 176 pins, and creating a default project initializes application that uses a processor with 324 pins.

It is possible to change the processor used in the project ('Components'->'Processor' etc) for the one I need, but then all the cores have their memory mappings reset.

I am attaching a table that summarises the changes.

	Z4_0 (before applying changes)	Z4_0 (new pin package)	Z4_1 (before applying changes)	Z4_1 (new pin package)	Z2 (before applying changes)	Z2 (new pin package)
flash_base	0x01000000	0x01000000	0x11d0000	0x01000000	0x13a0000	0x01000000
sram_base	0x40000000	0x40000000	0x40040000	0x40000000	0x40080000	0x40000000

Additionally, all cores have their core1_intc_sw_handlers.S file from /Project_Settings/Startup_Code/ swapped with core0_intc_sw_handlers.S.

I simply need to flash a second core into a project that uses already one core, and it fails. Could this be the reason?
I tried resetting the values to the initial state, this however doesn't help - I am still unable to flash the second core.

Does resetting the Pin Package change other values/variables? Which ones?

How to change a Processor in a multicore application to keep using the multi-core functionality?

[raresvasile]

Hello,

Please make sure that in the CPU component for each core, the correct id of the core is selected.

E.g. for Z4_1:

After the configuration is set, regenerate the code and the proper linkers and startup files will be added.

Best regards,

Rares

[lukaszadrapa]

It was logged as a bug but I'm afraid that the fix won't be available earlier than in Q4.

It should be sufficient to manually replace the content of linker files and startup files with original content after changing the package. Is this working for you?

Regards,

Lukas

[pmrlcbtcphtzjdq]

Unfortunately changing the content of linker files and the startup file doesn't help - I still can't flash anything more than the first core of the board.

Are there any other changes relevant to memory and flashing, that are made when changing the pin package of the processor?

I already made a thread about my issues with flashing/debugging here-any help would be appreciated.

[lukaszadrapa]

Hi,

I did following test on my side:

- created new multicore project for Z0 and Z1 cores, SDK 3.0.3 selected for both cores

- tested the project to be sure it works

- did a backup of the project

- changed package to 176pin on both Z0 and Z1 and switched IO configuration as required by processor expert

- then I generated code for both Z0 and Z1 projects - this is what overwrites linker file and startup file of Z1 core. There was a warning message about that

- I manually replaced the content of linker file and startup file with original content from backup (I didn't change name of the startup file on Z1)

- I compiled the project and selected Launch Group from Debug Configuration, so both projects are loaded and I can debug it as multicore

- I tested the projects and also compared the flash content -> it is OK, it works.

And I can see that if I generate code again on Z1, the files are not overwritten again, so there's no need to update the content each time.

If you do it in this way, is it working on your side?

Regards,

Lukas

[pmrlcbtcphtzjdq]

Thanks a lot for the answer. I followed your tips and was able to reproduce the behavior, however, my goal is to flash a single core (or just the cores separately) using the elf files. This fails.

I am able to debug the application when all the cores are grouped in a 'launch group'. This is not enough. First of all, this applies only to debugging, and the second problem is that I am not able to select only the second core and flash the board with it separately, independently of the content of the first core on the board. I need to be able to upload single cores' elfs to the board. Additionally, it is also not possible to create 'launch groups' for flashing, so I can't choose the .elf files I wish to have on the board and flash them together.

When trying to flash a single elf file onto the second core I am using these commands: 'Flash from File... ' > [debug configuration for second core ] > 'Flash' and it fails. Initially, the debugger stops at 90% at 'Configuring GDB' and after few minutes comes back with this message:

Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:7226
Error message from debugger back end:
localhost:7226: The system tried to join a drive to a directory on a joined drive.

I tried enabling the checkbox 'Launch Server Locally; in the debugger settings (at 'GDB Server Settings' field), and this results in a different error, that says:

Connection from "127.0.0.1" via 127.0.0.1. Connection from port "49315" to 7226
PE-ERROR: Warning. Can't read registers while part is running.
PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes)
PE-ERROR: Warning. Can't read memory while part is running. @11d320c (4 bytes)
Interrupt command received. Halting execution.

 I don't know how to flash an .elf file onto the second core.

ps

I figured out that after changing the processor package the S32DS sets it by default to Z4_0. If you click on the 'Processor' Component and reset it to the desired core BEFORE clicking 'generate processor expert code', then all the initial settings (linker and startup files) remain as they were - divided for the multi-core functionality.

[pmrlcbtcphtzjdq]

I managed to find a workaround for the problem of flashing the second core. This solution doesn't help with flashing a single .elf file into a specific core but allows to run the desired combination of .elf files on the device.

1. click the 'run' button.

2. chose 'run configurations'.

3. set up a launch group with the desired .elf files for the cores you wish to flash. These cores need to be in the 'debug' mode, and it needs to use flash memory. run this configuration.

4. enter the debug mode and stop all the debugging.

5. unplug the device and plug it again - the program for both cores is stored now in flash memory.

[lukaszadrapa]

Hi,

I confirmed the behavior on my side, I just reported it to SDK team.

Regards,

Lukas