AM263P4: How To "Update The Calibration"?

Hi Kier,

While I am also checking in withour team to better understand this. Allow me to come back on this by Friday.

Please take a look at our compiler documentation on this topic: https://software-dl.ti.com/codegen/docs/tiarmclang/rel1_0_0_sts/tiarmclang_ug/tiarmclang-portfolio/compiler_manual/program_loading_and_running/run-time-initialization-slau1316977.html

Thanks for the manual link. I guess the choice of RAM or ROM model is something to consider but perhaps not critical to my question because both require modification of the object file in OSPI which is the tricky part.

If a better explanation of my use case is required, a more eloquent description is in this document: https://cdn.vector.com/cms/content/application-areas/ecu-calibration/xcp/XCP_Book_V1.5_EN.pdf

Please see section "3.1. Parameters in Flash"

Hi Kier, 

Is your application running from flash or from RAM?

If it is running from RAM, then map file can give you location of .cinit table, which would be in RAM.

If it is XIP, then writing to flash while code is executing from there, would need special IP like FOTA to write to flash 

Also below explains boot seg feature of OTFA IP, if it helps: software-dl.ti.com/.../bootseg_ip_working.html

HI Nilabh,

Our application runs in RAM. The map file only gives the location of .cinit table in RAM. I need the location of the .cinit table(s) in the OSPI flash in order to change it.

Visually speaking I need to do this:

I suppose the question is: How can I calculate the address of .cinit in OSPI flash?

Hi Kier,

Let me get back on this by early next week.

Any ideas? I guess the question boils down to how to calculate where .cinit is located in the .appimage or .mcelf.

Apologies Kier for the long delay, I was OOO due to travels.

I am looping in our MCELF expert in this thread.

Though there are some consideration which is concerning to me. Given the update will be done to an signed mcelf image, if you update .cinit section you will need to update the hash and the signature also, how would that work.

Also do you plan to use encypted image or non encypted?

Nilabh Anand said:

Though there are some consideration which is concerning to me. Given the update will be done to an signed mcelf image, if you update .cinit section you will need to update the hash and the signature also, how would that work.

That is a very good question. I don't think it would work now that I think about it, not without a great deal of effort.
At the very least I would have to move the .cinit (or its equivalent) outside of any signed area but that itself brings complications.

I think for now, I will park this question. My backup plan is to use EEPROM to store individual calibration values for now, a much simpler concept to work with.

Thanks for the pertinent questions.

Seems like we've run into similar issues.. we're also investigating options for our project on the same topic of dealing with calibration files. (link)

In addition to the X509 signing, the part which makes this tricky is that the whole toolchain is set up to be flash-location agnostic. Flashwriter ignores section load adresses in the mcelf, instead just flashing single 'blocks' (such as the full .mcelf). As such, calibration sections in flash won't ever be located in the same place. 

The way we're trying to get around it is to implement section-based checksums or hashing, and ensuring flashwriter is adapted to follow section load adresses. Then you can flash one or more sections as desired, as per the original mcelf intent. Does need a custom HsmRT image, on which there's not a lot of info.

Another issue I've found with this so far is that for some reason, the CCS debugger uses section load adresses vs run adresses to load programs into ram.. meaning a defined flash layout is very difficult to achieve. Time to dust off the Lauterbach.

As you say, probably best to find alternatives.. a very complicated process for something which used to be straightforward.

Thanks for your comments Rens. I think you're much further ahead in your considerations than me but good to know it's not just me wondering how we can implement these features when you have no embedded flash.