s32k1 bootloader examples for app notes do not compile with S32DS 3.5

[dparkinson]

In starting a bootloader for my project that uses an s32k116, I found the application notes for the S32K1 with example code (s32k146, s32k148, s32k144). When import the example project into S32 Design Studio for S32 Platform, v3.5 , it does not compile. I get the  attached error screenshot. 

 

I have not modified the projects in any way. 

I've used the examples for the following application notes

https://www.nxp.com/docs/en/application-note/AN12218.pdf

https://www.nxp.com/docs/en/application-note-software/AN12218SW.zip

https://www.nxp.com/docs/en/application-note/AN12323.pdf

https://www.nxp.com/docs/en/application-note-software/AN12323SW.zip

Is there a different example for S32DS 3.5?

[dparkinson]

@VaneB ,

How can I allow function execution from a pointer that I assign the address by value? 

It seems it is not related to RAM, specifically. my settings or something does not run if I specify the pointer to the drivers using the memory address. 

I tried just defining a dummy function in my project and put it in the flash_driver flash space. function does not perform any flash activities If I use a function pointer that points to the function by name, it works ok. But if I point to the address in flash, to call the function, then it still throws the exception. 

It generates the same code for the function, either way.

It seems the IDE, debugger, or something does not like this:

__attribute__((section(".flash_driver")))

__attribute__((optimize("O0")))

status_t test_func(void)

{

      status_t result = STATUS_SUCCESS;

      return result;

}

typedef status_t (*test_ram_func_t)(void);

g_ptestFunc = (test_ram_func_t)(uintptr_t)0x0000E800u;

But is ok with this  g_ptestFunc = test_func;

[dparkinson]

Hi @VaneB , 

I moved everything over to using the unified bootloader with RTD. However, as soon as the code reaches trying to execute the flash drivers that are executing out of RAM, the debugger throws an exception.

Do I need to do something special in the linker or some setting to be able to execute code from the flash_driver portion of RAM?

I did not rewrite the ram flash driver with RTD, since that is only provided as a binary in the unified bootloader example. I did confirm in the debugger that the flash driver is in RAM. 

The original project that used an old SDK works in the debugger in S32DS 3.5 and performs the bootload.

I'm attaching the project, if there's something you can see that is messed up?

I'm not attaching the toolchain files. I'm using RTD 2.0.0 for S32K1 processor. I am including the ECU-pro project that I've been testing with over the CAN bus. It skips the flash_driver.bin download. Instead, I have the flash_driver.bin converted to flash_driver.o and I compile it into a portion of flash. Then, my code copies that to RAM at startup. That modification seems to work fine. 

Below are a couple screenshots from where the debugger fails. (It works when in the SDK version). 

flash driver in RAM is the same as flash_driver.bin (with updates for pointer offsets)

[VaneB]

hI @dparkinson 

These applications were developed using S32 Design Studio for Arm. Over time, updates to the IDE have introduced changes to elements such as toolchain paths, library paths, and SDK configurations.

To ensure compatibility with the currently used IDE version, it is recommended to create a new project. Then, manually copy the application’s source files and any custom project settings from the original project into the new one. This approach helps avoid integration issues caused by version-specific differences.

BR, VaneB

[dparkinson]

Thank you for the response.

Are there any example S32K1 bootloader projects that work with S32DS?

3.5 prefer, but I'd be willing to try 3.4 or 3.6 if that's the only one available). 

I would like to start with a known working project before I started to modify it for use with the S32k116. 

[VaneB · Accepted solution]

Hi @dparkinson 

For S32K1 devices, the available bootloader applications include the ones you have already shared, as well as the Unified Bootloader Demo. At the moment, there is no bootloader application developed specifically for S32DS version 3.4 or later.

[jianghao]

Hello, bro, I have the same Question, did you transplant the code successfully?

[dparkinson]

@jianghao , I did get a unified bootloader version for the s32k116 that uses the RTD. It is attached. I have also attached the ECU Pro project that loads the app over CAN from the PC once the bootloader is running. 

notes:

• the flash driver is embedded in the bootloader program. This is different from the original demo. the original bootloader demo dowloaded the flash driver over CAN as part of the app update process. 
• the flash driver is stored in the m_store_flash_driver in internal flash memory. the bootloader copies this section to RAM space, m_flash_driver at startup. see linker file. 
• the flash driver runs in RAM space during update process because you can't write to internal flash while executing from it. So the flash driver has to run from RAM.
• note the s32k116 has only one bank of internal flash. other variants have more banks. for those, I think it could be possible to run your flash driver from the 1 bank while updating the 2nd bank of flash. 
• I attributed the internal flash driver generated by the RTD so it is stored in the m_store_flash_driver space. If you re-generate the RTD driver, then you may lose this attribution. See Ftfc_Mem_InFls_Ip.c for example
• the attribute is the following. you can search for where-used. 

__attribute__((section(".flexnvm_flash_driver")))​

• Note that the flash driver is not stored in the flexnvm bank. Originally, I was going to put the flash driver in flexnvm and not do RAM execution, but I changed course and decided to use the flexnvm as EEPROM in my app. I did not update the attribute/section name. (I don't know if execution from flexnvm works or not as I changed course before I got that far). 
• the app is just the demo app and I don't think will jump back to bootloader for the next update. I did not really test as I moved on to using different bootloading protocol. 
• built/tested with 
  • NXP S32 Design Studio for S32 Platform v3.5 Build id 240924 (Update 14)
  • S32K1 Real-Time Drivers Version 2.0.0 QLP1
  • evaluation board s32k116EVB2Q048
  • EcuBus Pro v 0.8.49
  • PEAK PCAN-USB for PC/CAN interface

[dparkinson]

@VaneB ,

Thank you.  I'm starting to to work on migrating code. I'll try to post if I get something that works with S32DS. progress so far

•  started with example for AN12218 on S32DS 3.5, but couldn't easily figure out where missing defines were for files under src/drivers/ subfolder, so put that on hold. 
• installed S32 for Arm 2018.R1 and got all of the examples to compile ok with that IDE.  
•  I started looking at the  Unified Bootloader Demo. the S32116 variant also compiles under S32 for Arm and compiles for me under S32DS 3.5. When in s32 for Arm, I can use the processor expert to try to figure out what the drivers are included and such. 
• So, right now, I guess I'll try the unified bootloader and see if I can figure out how to migrate it to S32DS 3.5 using RTD instead of whatever drivers it's using for S32 for ARM.