Bootloader placing at S32K148

[christofhaiding]

Hi!

At the moment we are trying to implement the A/B FW update/start mechanism.

Currently we are a litte confused about the implementation style.

In the Application Note AN12323 it is described in a way that the Bootloader should be located at the NVM RAM

Other guides, for example "FTF-AUT-N1795 S32K Architecture and Capabilities to Enable Over the Air Updates.pdf" suggest the placing on top of the P-Flash.

Placing the bootloader at the NVM disables it capabilities to write to an emulated EEPROM.
On the other hand, placing it in NVM enables us to use the whole P-Flash capacity.

Which one is the best way to implement this function?

Thx for the answer in advance

Christof

[christofhaiding]

Hi Lukas!

Is there any application note for this?

Because at the moment I am a little bit confused.

Just for better understanding:

The P-Flash of the S32K148 is devided in 3 Parts.
Part 1 and Part 2 can be used for the Application, with the advantage that if the application is excecuted from , let's say Part2, part 1 can be updated with the new application.

Am I right?

If we place the Bootloader in Part 3, the bootloader can access the emulated EEPROM.

And it is also possible to update the Bootloader during an started, let's stick with the example Part 2, application?

And thats the recommended way for the S32K148, am I right?

Still my question, just for clearance:

Any application which is placed in the NVRAM, is not able to make an write access to an emulated EEPROM?

Regards

Christof

[lukaszadrapa]

Hi Christof,
I'm afraid there's no such application note.

"The P-Flash of the S32K148 is devided in 3 Parts.
Part 1 and Part 2 can be used for the Application, with the advantage that if the application is excecuted from , let's say Part2, part 1 can be updated with the new application. Am I right?"

- Yes, that's correct.

"If we place the Bootloader in Part 3, the bootloader can access the emulated EEPROM."

- The reference manual says:
"The last partition (448KB Program Flash and 64KB Data
Flash/FlexMEM), being a single read partition which is
shared, needs consideration as code may not execute from
the 448KB Program Flash area at the same time as the
64KB Data Flash/FlexNVM area is being accessed."

But there's simple workaround - execute the code from RAM memory (like functions which read/write the EEE). You can use these macros to force a function to RAM:
START_FUNCTION_DEFINITION_RAMSECTION
END_FUNCTION_DEFINITION_RAMSECTION

Notice that interrupts should be either disabled or all the resources related to interrupts need to be moved to RAM too.

"And it is also possible to update the Bootloader during an started, let's stick with the example Part 2, application?"

- Yes. If the code runs from Part 1 or Part 2, you can update Part 3.

"And thats the recommended way for the S32K148, am I right?"

- Yes.

"Any application which is placed in the NVRAM, is not able to make an write access to an emulated EEPROM?"

- NVRAM - do you mean FlexRAM? There's no such option at all because if Emulated EEPROM is enabled, whole FlexRAM is used for EEE. If you want to use FlexRAM as a system RAM, the emulation needs to be disabled.

Regards
Lukas

[lukaszadrapa]

Hi Christof,

"Placing the bootloader at the NVM disables it capabilities to write to an emulated EEPROM.
On the other hand, placing it in NVM enables us to use the whole P-Flash capacity.

Which one is the best way to implement this function?"

If you want to use S32K148, you can have both advantages at the same time.

The application note talks about S32K146 in case of A/B swap:

 S32K148 has even more flash.

So, first two blocks can be used for applications and the Program part of the shared block for bootloader and FlexNVM part can be still used for EEPROM.

Regards,

Lukas

[christofhaiding]

Hi Lukas!

Thx for the answer

Am sry for asking again.
If you mean the sectioning of 1+2+3 you don't mean it this way:

That was exactly the problem we encountered, because we set the Bootloader to the FlexNVM (0x1000 0000) and could not have an writting access to the emulated EEPROM.

You suggest that the partitioning should be this way?

With part 1+2 as holder for the application and part 3 as holder for the bootloader?

Thanks for the tip with locating the source to the RAM section.

Wie will try this.

Regards

Christof

[lukaszadrapa]

That's a good question. I'm sorry, I can see that my previous answer is inaccurate. I was talking about mix of S32K146 and S32K148.
In case of S32K148, it makes sense to to have 3 partitions in program flash (bootloader + app1 + app2) as on your second screenshot and last 512KB block can be used for Emulated EEPROM + normal data flash storage if needed.
This is the most straightforward solution, I think. The only disadvatange is that you will have one 512KB block dedicated only for bootloader which is usually small.
If you need more memory for applications, it would be necessary to use also block with the bootloader and 448KB block. It's doable too, but more complicated.
Regards,
Lukas

[christofhaiding]

Hi Lukas!

Thanks for your answer.

We will try it as you said.

But one more question for the Option "START_FUNCTION_DEFINITION_RAMSECTION".

In my understanding, it means that althought the rest of the bootloader is located/excecuted from the FlexNVRAM.

Functions which have this options, are located at the FlexRAM am I right?

So theoretically, I am placing the bootloader into the FlexNVRAM, but the function which writes the EEPROM data is compiled with this option should be able to write into the EEPROM.

Right?

Regards Christof

[lukaszadrapa · Accepted solution]

It does not force the code to FlexRAM but to normal RAM by default. Now I found that there are actually two kind of macros - for declaration and for definition.

It's important to use declaration like this (example taken from source files):

START_FUNCTION_DECLARATION_RAMSECTION
static status_t FLASH_DRV_CommandSequence(const flash_ssd_config_t * pSSDConfig)
END_FUNCTION_DECLARATION_RAMSECTION

This is using:

__attribute__((section (".code_ram")));

Macros:

START_FUNCTION_DEFINITION_RAMSECTION
END_FUNCTION_DEFINITION_RAMSECTION

... will do nothing because (note from the source files):

/* For GCC, IAR, GHS, Diab and ARMC there is no need to specify the section when
defining a function, it is enough to specify it at the declaration. This
also enables compatibility with software analysis tools. */

So, yes, when doing this, you can execute the code from shared 448KB block and you can still access EEE. Just be careful about the interrupts as already mentioned.

Regards,

Lukas