S32K358: Core clock enable when debugging (IPCF example)

[AndreasStolze]

Hi,

I am currently trying to understand the boot process of the S32K358 being a multicore processor.

Based on the documentation and the IPCF example, is seems like the Boot configuration word is relevant, which is stored in the IVT. I can enable cores on boot here.

This is shown as well in the IPCF example:

Snippet from startup_cm7.s:

.section ".boot_header","ax"
  .long SBAF_BOOT_MARKER /* IVT marker */
  .long (CM7_0_ENABLE << CM7_0_ENABLE_SHIFT) | (CM7_1_ENABLE << CM7_1_ENABLE_SHIFT) | (CM7_2_ENABLE << CM7_2_ENABLE_SHIFT) /* Boot configuration word */

Snippet from linker file:

MEMORY
{
    int_flash_c0               : ORIGIN = 0x00400000, LENGTH = 0x00200000    /* 2048K */
}

.flash :
    {
        KEEP(*(.boot_header))
        . = ALIGN(2048);
        __text_start = .;
        __interrupts_init_start = .;
        
       ...

    } > int_flash_c0

There are multiple debug configuration available. A combination of Release/Debug and Flash/RAM.

When looking at the RAM linker files, boot_header is dropped:

   /* Discard boot header in RAM */
   /DISCARD/ : { *(.boot_header) }

So I don't understand how how the cores are enabled, since the reset value is equivalent to disable all cores on startup.

Is there something happening in the background by the debugger? Or is this something I can see in the debug configurations?

Remark: I am currently using a PEmicro debugger.

Thanks
Andreas

Edit: It seems like the address of the interrupt vector table would also be missing if the boot_header is not included.
For Core 2 this seems obvious, as the RAM debug config sets the appropriate PC and thus avoids needing to set the IVT / start address. But not sure how it works for Core 0.

[Nhi_Nguyen]

Hi @AndreasStolze ,

The processing of boot core as below:

IVT structure:

For example:

So, IVT stored in flash. You can also check this in map file:

In startup VTOR will copy to RAM, like that:

You can refer to some files startup.s, vector_table.s  in platform and run any example that was attached in the package to get detail.

Best regards,

Nhi

[Drifter22]

Hello @Nhi_Nguyen , related to the Andreas Stolze question: core enabling by using CM7_0_ENABLE, CM7_1_ENABLE, etc. (bits into Boot Configuration Word) are correctly read even if both HSE firmware and HSW firmware feature flag are not programmed and BOOT_SEQ = 0 (nonsecure boot usage), as default configuration.
My doubt raised because of this sentence into RM (table attached in previous answer): "SBAF uses this field only when the HSE firmware usage feature flag is enabled and BOOT_SEQ field is 0." In my case HSE firmware usage feature flag is DISABLED because I don't use HSE.
Thanks

[Nhi_Nguyen]

Hi Differ22,

These were captured from RM:

As you can see, there is difference between description of core CM7_3 with the remaining cores.

From this, as far as I know, we need to configure parameters to start application cores (CM7_0-CM7_3) and follow to sequence:

Core start address is where store VTOR that can't miss in the boot processing. Furthermore, as my understanding, when chip said that a field is ignored when it see specific condition, this means that if you configure this field, it not cause problem. I tried to remove this field but core can't boot correctly.

So, from my point of view, you need to configure this field.

Best regards,

Nhi